Пути к файловой системе и Directory.Exists ()

Question

Я немного растерялся из-за этого ... не могу понять, что происходит.

У меня есть приложение, которое записывает некоторые файлы в настроенный выходной каталог, но до этого, когда приложение загружается, я делаю это ...

string path = ConfigurationManager.AppSettings["TempDir"];
if (!Directory.Exists(path))
    Directory.CreateDirectory(path);

Моя проблема в том, что в моем случае путь является сетевым местоположением "\ MyServer \ Share", и когда я использую этот путь, он работает, но путь, который я использую, на самом деле - "Z: \", потому что общий ресурс сопоставляется и автоматически сопоставляется во всех пользовательских сеансах в сети.

Я хочу использовать "Z: \", но это не работает, возвращая ошибку, говорящую, что "весь или часть пути не существует".

Я сразу подумал: "О, это должны быть разрешения", поэтому я проверил его, скажем, "G: \", который работал и к нему применены те же разрешения ...

Для всех рассматриваемых акций моя учетная запись пользователя имеет полные права доступа к местоположению.

Первоначально я думал, что это может быть что-то вроде этого: Directory.Exists не получает сопоставленный каталог Но потом я вспомнил, что не может быть, чтобы приложение работало под другой учетной записью, потому что я проверил и

1. это единственное консольное приложение

2. следующая строка:

   AppDomain.CurrentDomain.SetThreadPrincipal(new WindowsPrincipal(WindowsIdentity.GetCurrent()));
   

.. как я понимаю, цель этого состоит в том, чтобы убедиться, что домен приложения работает в контексте текущего пользователя Windows, включая все «потоки, созданные в домене приложения», если не указано иное

Есть идеи?

EDIT:

Просмотр монитора процессов, как предлагает Ричард (см. Комментарии ниже), показывает, что если я использую полный путь unc "\ MyServer \ Share", то запрос выполняется так, как я и ожидал, если я использую сопоставленный путь "Z: \" он по-прежнему запрашивает полный путь unc "\ MyServer \ Share" (предположительно, он выполняет некоторую форму перевода во внутренней работе .net).

так что независимо от того, что я запрашиваю полный путь unc "\ MyServer \ Share", и все же, только явно указав полный путь unc, я могу получить к нему доступ ... странно !!!

Вышеприведенный код точно такой же, как я написал его в моем консольном приложении, но пока нет ничего другого, кроме этого принципа, поскольку это первые строки кода, которые должны быть выполнены в моем консольном приложении.

Хммм ...

РЕДАКТИРОВАТЬ 2:

Хорошо, теперь я действительно сбит с толку, когда ставлю точку останова в строке запроса файла конфигурации выше и запускаю ее до точки останова, затем очищаю монитор процесса и перешагиваю через него, и в операторе if ничего не появляется в мониторе процесса, пока я ожидал бы это ...

Почему это случилось?

Answer 1

Кажется, я обнаружил странную ошибку в инструментах отладки / .net framework ... Когда отладчик подключен к моему приложению, он выходит из строя, а когда отладчик не подключен, он работает как положено.

Рекомендуется всегда использовать полный путь unc, но вызовы Directory.Exists (путь) и Directory.Delete (путь) разрешают сопоставленные диски перед выполнением вызова, так как монитор процесса обнаруживает, поэтому, хотя рекомендуется, что это не требуется .

Однако я обнаружил, что запуск приложения с последующим подключением Visual Studio вручную, по-видимому, позволяет приложению работать должным образом и разрешать отладку в моей ситуации.

Это решение поставляется только с гарантией "Работает на моем ПК" ... Я не несу ответственности за все, что сказано в этом вопросе:)

Спасибо всем за помощь, однако я, кажется, решил ее ... UAc был хорошим советом, как и монитор процесса ... спасибо, ребята ... действительно помогли:)

Answer 2

Вы не можете использовать подключенный диск в качестве пути, необходимого для создания общего каталога и предоставления ему необходимых разрешений (чтение или запись), а затем подключиться к нему следующим образом: \ ServerName \ SharedDirectoryName \ OneMoreDirectory