Laden...

Application.ExecutablePath und Effekte durch Sonderzeichen im Path

Erstellt von Eco vor 9 Jahren Letzter Beitrag vor 9 Jahren 3.181 Views
Information von herbivore vor 9 Jahren

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!

E
Eco Themenstarter:in
12 Beiträge seit 2014
vor 9 Jahren
Application.ExecutablePath und Effekte durch Sonderzeichen im Path

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ß

771 Beiträge seit 2009
vor 9 Jahren

Hi,

warum siehst du dadrin ein Problem? Benutze für Pfadoperationen immer die Path-Klasse und es ist egal, welcher Separator benutzt wird.

49.485 Beiträge seit 2005
vor 9 Jahren

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

E
Eco Themenstarter:in
12 Beiträge seit 2014
vor 9 Jahren

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.

Hinweis von herbivore vor 9 Jahren

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