Hallo zusammen,

langsam fange ich an an mir selbst zu zweifeln...
Ich habe mich das erste mal an ein Net6 Projekt gewagt, da es eine kleine Konsolenanwendung werden soll und es als "Kennenlernen" ganz gut ist.

Das Programm soll einen Dateipfad (Pfad zu einer XML-Datei) als Parameter erhalten. Leider wird hier diese Datei "escapt" weil im Pfadnamen \n vorkommt.
Im Detail sieht der Pfad so aus:
C:\Visual Studio\VS2022\Test\bin\Debug\net6.0\diexmldatei.xml

Als Argument (Project - Projektname.Properties - Debug - General - "Open debug launch profiles UI") habe ich folgende Zeichenfolge eingegeben:
-x:"C:\Visual Studio\VS2022\Test\bin\Debug\net6.0\diexmldatei.xml"

Nach dem Start wird dieses Argument leider zu
"-x:C:\\Visual Studio\\VS2022\\Test\\bin\\Debug\net6.0\\diexmldatei.xml"

Nun erhalte ich immer einen Zeilenumbruch nach dem Debug (aufgrund \n)

Bei einem FW 4.6 Projekt wird der Pfad in den Argumenten korrekt zurückgegeben:
"-x:C:\\Visual Studio\\VS2022\\Test\\bin\\Debug\\net6.0\\diexmldatei.xml"

Hatte schon jemand dieses Phänomen bzw. finde ich irgendwie auch keinen Ansatz das zu korrigieren...

LG
fichz

Hat nichts mit .NET zutun, sondern ein Fall von Escaped Values in Deiner launchsettings.json

Führ Deine Anwendung manuell aus

Zitat

ConsoleApp.exe -x:"C:\Visual Studio\VS2022\Test\bin\Debug\net6.0\diexmldatei.xml"

Und es passiert kein NewLine.

Naja das mag schon sein wenn die Anwendung dann später released wird, aber ich will meine Anwendung ja auch debuggen.
Gibt es hier keine Möglichkeit?

Ich habe mir die "launchsettings.json" nun angesehen (kannte ich vorher noch nicht). Da steht es ja auch korrekt drin:

{
  "profiles": {
    "Profilname": {
      "commandName": "Project",
      "commandLineArgs": "-x:\"C:\\Visual Studio\\VS2022\\Test\\bin\\Debug\\net6.0\\diexmldatei.xml\""
    }
  }
}

Arbeitet ein FW 4.6 Projekt da generell anders?

LG

\n ist ein reserviertes Zeichen in Json, da kann weder Visual Studio noch .NET etwas daran ändern.
Musst mit / arbeiten statt \.

Zitat

Arbeitet ein FW 4.6 Projekt da generell anders?

Wie gesagt, hat nix mit .NET zutun.
.NET FX Projekte verwendet keine Json- sondern XML-Config Dateien für sowas.
XML hat aber ebenso gewisse reservierte Zeichen, \n gehört aber nicht dazu.
Verwendest mit .NET 4.6 ne Json Datei hast das gleiche Problem.

Hallo Abt!

Mit / funktioniert es nun, danke für den Hinweis!

Aaaaber:
Wenn es nichts mit .Net zu tun hat, hat es etwas mit Visual Studio zu tun. Denn irgendwer hatte ja die Idee json als Dateiformat für Startparameter beim Debuggen zu verwenden.
Und da finde ich (ist nur meine Meinung), wenn es keinen triftigen Grund dafür gibt - oder die Vorteile so überwiegen - dieses Format eventuell nicht das Beste ist. Denn es gibt ja noch andere Zeichenfolgen welche escaped werden könnten.

LG

Auch mit VS hat es nichts zu tun.
Es liegt einfach an json selbst.
Und json für die Configs ist zum einen flxibler und auch kompakter als die alten XML Configs.
Gerade wenn man schon seit .NET 2.0 dabei ist, merkt man was für Welten dazwischen liegen.
Ich muss hier teilweise noch mit mehreren KB großen XML Configs mit Meterlangen AssemblyRedirects arbeiten.
Deshalb fährst du mit json um eingies besser.

Ansonsten muss man halt die Unterschiede einmal kennen lernen, dann ist es zukünftig kein Problem.
Da json auch im .NET Umfeld seit Jahren etabliert ist, sollte sich dies auch für dich nicht als schwer darstellen.

T-Virus

XML hat seine Vorteile, Json hat seine Vorteile - und beide Nachteile.
Die Entwicklergemeinde ist ganz klar pro Json und hat dafür gesorgt, dass das eben so ist, wie es heute ist.
Sei froh, dass es kein YAML ist - aber ich will es auch nicht prophezeien ;-)

Tatsächlich scheint das eigentlich aber funktionieren zu sollen (da VS hier offenbar vor dem eval parst), aber ist derzeit eine Regression.
https://developercommunity.visualstudio.com/t/VS-2022-1721-regression-issue-wrt-laun/10047194?space=8&q=launchsettings+newline

Ich beschwere mich nicht, da man - wie du sagst - die Eigenheiten kennen und dann dementsprechend reagieren muss. Und ich verstehe jetzt auch den Hintergrund warum json verwendet wird, wenn es dann wirklich gewisse Dinge einfacher macht.

Ich dachte halt, dass hier VS eventuell einen Mechanismus eingebaut hat, dass solche Zeichenfolgen einfach nicht escaped werden (oder eine Option zum Aktivieren ob man das will oder nicht). Auch wenn es json ist will vermutlich kein Entwickler, dass die Programmparameter escaped werden.

Für solche "Komfort"-Funktionen hat man ja mMn. auch eine Entwicklungsumgebung wie VS welchen einen gewisse Dinge abnimmt.

LG
fichz

EDIT: Nach dem Posten erst den Post von dir gesehen Abt. Ok dann war ich ja vermutlich mit meiner Annahme recht, dass dies so nicht sein sollte. Aber gut, dass dies in Zukunft ja wahrscheinich behoben wird