C # - получить путь к файлу из файла конфигурации - @ не делает это волшебно - PullRequest
3 голосов
/ 27 апреля 2010

В настоящее время я работаю над веб-сервисом, который извлекает сообщение XML, архивирует его и затем обрабатывает. Папка архива читается из Web.config. Вот так выглядит метод архива

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");
    }

Структура пути, которую я извлекаю: C: \ Program Files \ Subfolder \ Subfolder. В средах разработки, QA, UAT и PRD все работает отлично. Но на другом компьютере мне теперь нужно установить веб-сервис (который, к сожалению, я не могу отладить), строка каталога - «C: Files». Просто чтобы убедиться, что я дважды проверил версию .NET на разных компьютерах (я подумал, что, возможно, использование @ до того, как строка будет зависеть от версии); все машины используют 2.0.50727.

Кто-нибудь знает эту проблему?

Заранее спасибо!

РЕДАКТИРОВАТЬ: я вижу @ перед переменной каталога вызвало некоторую путаницу в отношении вопроса, который я задал. Речь шла не об этом @ (на самом деле этого не должно было быть. Я его убрал).

Мой вопрос (перефразированный): когда вы помещаете символ @ перед строкой в ​​кавычках, например @ "c: \ folder \ subfolder", это гарантирует, что обратные слеши не будут интерпретироваться как escape-символы, верно? Что может быть причиной того, что он работает на одной машине, но не работает на другой? (Между прочим, я согласен с ответами, в которых говорится об использовании Path.Combine. Мне просто любопытно, что вызывает такое противоречивое поведение)

Ответы [ 4 ]

7 голосов
/ 27 апреля 2010

Вы можете попробовать использовать Path.Combine () вместо String.Format ().Хороший пример здесь .

0 голосов
/ 27 апреля 2010

От твоего вопроса я думаю, что ты лечил:

@directory

Как будто он выполнял ту же функцию, что и:

@"c:\myfolder\"

Разница в том, что в первом примере вы можете использовать зарезервированное слово в качестве имени переменной, например @class (не привыкать его использовать), а во втором примере строка может содержать символы без экранирования, например .

0 голосов
/ 27 апреля 2010

Используйте Path.Combine (), например:

strFilename = CombinePaths(directory, _senderService) + DateTime.Now.ToString("MMMyyyy");
0 голосов
/ 27 апреля 2010

Когда значение извлекается из файла конфигурации, оно автоматически экранируется должным образом. Символ '@' в имени переменной каталога не устанавливает его в явном виде - он сообщает компилятору, что это именованный параметр. Например:

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

Оператор '@' в имени переменной означает не обрабатывать этот символ как зарезервированное слово. Позволяет создавать имена переменных с тем же именем, что и ключевое слово:

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

Кроме того, если полученное значение равно «C: Files», то это недопустимо, так как отсутствует «\». «C: \ Files» будет действительным.

...