Eine Kurzgeschichte über Pfade

Eine Kurzgeschichte über Pfade

In diesem Kurzbeitrag erläutere ich euch wie man sicher mit Pfaden in der Cross-Plattform Entwicklung umgeht.

Voraussetzungen

Folgende Voraussetzungen sind gegeben.

Eine appsettings.json Datei die wie folgt aussieht:

    "PlantUmlSettings": {
      "PlantUmlTheme": "plain",
      "PlantUmlArgs": "-jar plantuml.jar {0}\*{1}*{2} -o {3} -{4}",
      "PlantUmlEndTag": "@enduml",
      "PlantUmlExe": "plantUml\bin\java.exe",
      "PlantUmlFileSuffix": ".plantuml",
      "PlantUmlStartTag": "@startuml",
      "PlantUmlThemeTag": "!theme",
      "PlantUmlWorkDir": "plantUml\bin"
    }

Eine .NET Anwendung, die sowohl auf einem Windows, wie auch interaktiv im GitLab Runner gestartet werden kann.

Leider hatte ich dann immer folgende Fehlermeldung, als die Applikation im GitLab Runner gestartet worden ist:

/src/Sample.Cli\plantUml//bin//java.exe' with working directory '/builds/Sample/src/Sample.Cli\plantUml//bin'. No such file or directory

Detailbetrachtung

Um dem Ganzen ein wenig weiter auf die Spur zu gehen, habe ich mir eine Beispiel-Applikation geschrieben um das Verhalten auf beiden System zu betrachten.

        static void Main(string[] args)
        {
            var environmentVariable = Environment.ExpandEnvironmentVariables("tmp");
            var tempPath = Path.GetTempPath();

            Console.WriteLine($"Value for Environment Variable {environmentVariable}");
            Console.WriteLine($"Value for {nameof(Path.GetTempPath)} {tempPath}");

            Console.ReadKey();
        }

Lässt man dann das Ganze auf einem Windows System mit dotnet wie folgt laufen, sieht das Ergebnis dann so aus:

PS C:\Users\schae> dotnet run --project D:\_Development_Projects\Repos\ConsoleApp1\ConsoleApp1\ConsoleApp1.csproj
Value for Environment Variable tmp
Value for GetTempPath C:\Users\schae\AppData\Local\Temp\

Das Ergebnis ist wie gewünscht. Nun schauen wir uns das auf der WSL2 an.

root@GAMER-001:~/.dotnet# ./dotnet run --project /mnt/d/_Development_Projects/Repos/ConsoleApp1/ConsoleApp1/ConsoleApp1.
csproj
Value for Environment Variable tmp
Value for GetTempPath /tmp/

Schauen wir doch nun ob der Pfad auch existiert:

root@GAMER-001:~/.dotnet# cd /tmp/
root@GAMER-001:/tmp#

Und das ist der erhoffte Pfad.

Die Lösung

Nach ein wenig Recherchieren in der Dokumentation von Microsoft bin ich auf diesen Artikel DirectorySeperatorChar gestossen. Nicht dass er mir mit dieser Methode geholfen hätte, sondern vielmehr mit dem Auszug

The following example displays Path field values on Windows and on Unix-based systems. Note that Windows supports either the forward slash (which is returned by the AltDirectorySeparatorChar field) or the backslash (which is returned by the DirectorySeparatorChar field) as path separator characters, while Unix-based systems support only the forward slash

dass Windows auch Forward-Slashes unterstützt. Manchem wird das sicherlich schon bekannt gewesen sein aber ich selber werde wohl meine Arbeit mit Pfaden, auch in Windows in Zukunft nur noch mit Forwar-Slashes machen.

Nun habe ich das natürlich auch getestet und zwar in der powershell core.

PS C:\Temp> cd C:/Users
PS C:\Users>

Interessant ist der Umstand, dass wenn der Pfad bekannt ist, man den Tabulator betätigt, Windows automatisch Backslashes macht.

Nun sind überall wo Pfade verwendet werden, die Backward-Slashes durch Forward-Slashes zu ersetzen. Die appsettings.json sieht dann nun so aus:

    "PlantUmlSettings": {
      "PlantUmlTheme": "plain",
      "PlantUmlArgs": "-jar plantuml.jar {0}/*{1}*{2} -o {3} -{4}",
      "PlantUmlEndTag": "@enduml",
      "PlantUmlExe": "plantUml/bin/java.exe",
      "PlantUmlFileSuffix": ".plantuml",
      "PlantUmlStartTag": "@startuml",
      "PlantUmlThemeTag": "!theme",
      "PlantUmlWorkDir": "plantUml\bin"
    }

Nun sind auch keine Fehlermeldungen vorhanden, dass der Pfad nicht mehr gefunden werden kann.

Ein weiterer Punkt den ich mitnehmen werde, ist der, dass in Zukunft alles klein geschrieben wird. Auch Variablen im Windows.

Fazit

Mit einfachen Mitteln lassen sich unter Umständen Stunden des Debuggens oder der Fehlersuche vermeiden. Ich hoffe Dir hat der Beitrag gefallen.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

Verbinde mit %s