3 Stimmen

C# - Abrufen des Dateipfads aus der Konfigurationsdatei - @ tut nicht seine Magie

Ich arbeite derzeit an einem Webdienst, der eine XML-Nachricht abruft, sie archiviert und dann weiterverarbeitet. Der Archivordner wird aus der Web.config gelesen. So sieht die Archivierungsmethode aus

private void Archive(System.Xml.XmlDocument xmlDocument)
{
    try
    {
        string directory = System.Configuration.ConfigurationManager.AppSettings.Get("ArchivePath");

        ParseMessage(xmlDocument);

        directory = string.Format(@"{0}\{1}\{2}", directory, _senderService, DateTime.Now.ToString("MMMyyyy"));
        System.IO.Directory.CreateDirectory(directory);

        string Id = _messageID;
        string senderService = _senderService;

        xmlDocument.Save(directory + @"\" + DateTime.Now.ToString("yyyyMMdd_") + Id + "_" + System.Guid.NewGuid().ToString().Substring(0, 13) + ".xml");
    }

Die Pfadstruktur, die ich abrufe, lautet C:\Program Fichiers \Subfolder\Subfolder. In den Entwicklungs-, QA-, UAT- und PRD-Umgebungen funktioniert alles einwandfrei. Aber auf einem anderen Rechner, auf dem ich den Webdienst installieren muss (den ich leider nicht debuggen kann), lautet die Verzeichniszeichenfolge "C:Files". Um sicherzugehen, habe ich die .NET-Version auf den verschiedenen Rechnern doppelt überprüft (ich dachte, die Verwendung von @ vor einer Zeichenkette sei vielleicht versionsabhängig); alle Rechner verwenden 2.0.50727.

Kennt jemand dieses Problem?

Vielen Dank im Voraus!

EDIT: Wie ich sehe, hat das @ vor der Verzeichnisvariable für einige Verwirrung in Bezug auf die von mir gestellte Frage gesorgt. Es ging nicht um das @ (das dort eigentlich nicht hätte stehen dürfen. Ich habe es entfernt).

Meine Frage (umformuliert) lautet: Wenn Sie ein @ vor eine Zeichenkette in Anführungszeichen setzen, wie @"c: \folder\subfolder "Damit wird sichergestellt, dass die Backslashes nicht als Escape-Zeichen interpretiert werden, richtig? Was könnte die Ursache dafür sein, dass es auf einem Rechner funktioniert, auf einem anderen aber nicht? (Ich stimme übrigens mit den Antworten überein, dass man Path.Combine verwenden sollte. Ich bin nur neugierig, was dieses inkonsistente Verhalten verursacht)

7voto

Dan Diplo Punkte 24765

Sie könnten versuchen Pfad.Kombinieren() anstelle von String.Format(). Eine gute Beispiel ist hier .

0voto

Tejs Punkte 39916

Wenn ein Wert aus der Konfigurationsdatei gezogen wird, wird er automatisch richtig escaped. Das '@'-Symbol im Namen Ihrer Verzeichnisvariablen bedeutet nicht, dass sie 'explizit' ist - es teilt dem Compiler mit, dass es sich um einen benannten Parameter handelt. Zum Beispiel:

public void (string[] args)
{
   int length = args.Length;
   length = @args.Length; // Same thing!
}

Der '@'-Operator in einem Variablennamen bedeutet, dass dieses Symbol nicht als reserviertes Wort behandelt wird. Er ermöglicht es Ihnen, Variablennamen mit demselben Namen wie ein Schlüsselwort zu erstellen:

public static void Foo(object @class)
{
     //@class exists here, even though class is a reserved keyword!
} 

Außerdem ist der Wert "C:Files" ungültig, da ein "\" fehlt. ' C:\Files ' wäre gültig.

0voto

KMån Punkte 9806

Verwenden Sie zum Beispiel Path.Combine():

strFilename = CombinePaths(directory, _senderService) + DateTime.Now.ToString("MMMyyyy");

0voto

Fenton Punkte 221749

Aus Ihrer Frage schließe ich, dass Sie behandelt haben:

@directory

Als ob es die gleiche Funktion hätte wie:

@"c:\myfolder\"

Der Unterschied besteht darin, dass im ersten Beispiel ein reserviertes Wort als Variablenname verwendet werden kann, wie z. B. @class (gewöhnen Sie sich nicht an, es zu verwenden), und im zweiten Beispiel kann die Zeichenkette uneingekapselte Zeichen enthalten, wie z. B. .

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X