Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

Application.ExecutablePath und Effekte durch Sonderzeichen im Path

Moderationshinweis von herbivore (11.07.2014 - 07:43:31):

Dies ist ein Thread, auf den aus der FAQ verwiesen wird. Bitte keine weitere Diskussion, sondern nur wichtige Ergänzungen und diese bitte knapp und präzise. Vielen Dank!

Eco
myCSharp.de - Member



Dabei seit:
Beiträge: 12

Themenstarter:

Application.ExecutablePath und Effekte durch Sonderzeichen im Path

beantworten | zitieren | melden

Hallo zusammen,

ich habe ein merkwürdiges Phänomen i.V. mit System.Windows.Forms.Application.ExecutablePath und Sonderzeichen festgestellt.
Bisher konnte ich hier nur das Rautenzeichen ('#') identifizieren, welches im Pfad dafür sorgt, dass als nachfolgende Pfadtrennzeichen der Slash ('/') statt des Backslashes ('\') zurückgegeben wird.

Beispiel: Pfad des Executables "c:\test1\test#2\test3\test.exe", Rückgabe von System.Windows.Forms.Application.ExecutablePath: "c:\test1\test#2/test3/test.exe".
Wenn man es weiß, ist dem Problem natürlich recht einfach beizukommen.

Kann mir jemand erklären, warum dies so ist und ob es noch andere Sonderzeichen gibt, die das verursachen?

Besten Dank im voraus.

Gruß
private Nachricht | Beiträge des Benutzers
Cat
myCSharp.de - Member

Avatar #avatar-3070.jpg


Dabei seit:
Beiträge: 790

beantworten | zitieren | melden

Hi,

warum siehst du dadrin ein Problem? Benutze für Pfadoperationen immer die Path-Klasse und es ist egal, welcher Separator benutzt wird.
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo Eco,

vorneweg: ich halte das Verhalten für einen Bug des Framworks bzw. des zugrundeliegenden Windows APIs. Das kommt zwar extrem selten vor, aber es kommt in eher seltenen Spezialfällen eben doch manchmal vor.

An deiner Stelle würde ich mal die anderen Möglichkeiten aus [FAQ] Pfad zur eigenen Anwendung (EXE) ermitteln probieren, ob die vielleicht mit Doppelkreuzen in Pfaden klar kommen.

Über die Ursachen und über die Wirkung anderer Sonderzeichen kann nur spekulieren, halte es jedoch für wahrscheinlich, dass der intern der Pfad teilweise behandelt wird wie eine Url und die Probleme daher resultieren. In Urls hat das Doppelkreuz eine besondere Bedeutung, weil dahinter ein Anchor steht. Daher werden die folgenden Slashes wohl nicht mehr als Pfad-Trenner betrachtet und in Backslashes umgewandelt/angepasst, sondern unverändert durchgereicht.

Von daher würde ich vermuten, dass ein ähnlicher Effekt bei Verwendung eines Fragezeichens eintreten würde, das in Urls die Parameter einleitet. Das ist allerdings auch nur Spekulation. In normalen Pfadnamen sind Fragezeichen jedoch sowieso nicht erlaubt. Möglicherweise könnte ein Fragezeichen jedoch bei Pfaden auftauchen, die länger sind als 254 oder 255 Zeichen (siehe Naming Files, Paths, and Namespaces für die Namensregeln von Datei- bzw. Pfadnamen).

Andere Zeichen, die in Url den eigentlichen Pfad beenden und etwas anderes einleiten (als Parameter oder Anchor), fallen mir nicht ein. Daher würde ich erwarten, dass andere Sonderzeichen keine Probleme verursachen. Aber auch das ist wieder nur Spekulation.

Die Implementierung des Getters von ExecutablePath deutet auf jeden Fall darauf hin, dass Pfade teilweise wie Urls (=Uris) behandelt werden:

public static string get_ExecutablePath()
{
    if (executablePath == null)
    {
        Assembly entryAssembly = Assembly.GetEntryAssembly();
        if (entryAssembly == null)
        {
            StringBuilder buffer = new StringBuilder(260);
            UnsafeNativeMethods.GetModuleFileName(NativeMethods.NullHandleRef, buffer, buffer.Capacity);
            executablePath = IntSecurity.UnsafeGetFullPath(buffer.ToString());
        }
        else
        {
            string escapedCodeBase = entryAssembly.EscapedCodeBase;
            Uri uri = new Uri(escapedCodeBase);
            if (uri.Scheme == "file")
            {
                executablePath = NativeMethods.GetLocalPath(escapedCodeBase);
            }
            else
            {
                executablePath = uri.ToString();
            }
        }
    }
    Uri uri2 = new Uri(executablePath);
    if (uri2.Scheme == "file")
    {
        new FileIOPermission(FileIOPermissionAccess.PathDiscovery, executablePath).Demand();
    }
    return executablePath;
}

Siehe GetModuleFileName function für die Beschreibung der zugrundeliegenden API-Funktion, auch wenn ich darin keine direkten Hinweise auf den konkreten Effekt gefunden habe.

herbivore
private Nachricht | Beiträge des Benutzers
Eco
myCSharp.de - Member



Dabei seit:
Beiträge: 12

Themenstarter:

beantworten | zitieren | melden

Danke für Eure Antworten. Das Verhalten scheint sich auf "ExecutablePath" zu beschränken, die anderen Möglichkeiten der FAQ liefern stets Backslashes als Trennzeichen zurück.

Im konkreten Fall wurde leider nicht die Path-Klasse zur Verarbeitung des Pfades verwendet, sondern Substring-Operationen, die einen Backslash erwarteten.

Moderationshinweis von herbivore (10.07.2014 - 09:08:37):

Was wieder mal zeigt, warum man besser immer die Path-Klasse verwenden sollte. :-)

private Nachricht | Beiträge des Benutzers