System.UnauthorizedAccessException - Доступ к пути запрещен

Это немного сложный вопрос, так что несите меня ...

У меня есть небольшой простой метод:

Public Overloads Shared Function DoStuff(ByVal path As String) As Boolean
        If Not IO.File.Exists(ipath) Then Throw New ArgumentException

        Dim result As Boolean
        Using fs As FileStream = New FileStream(path, FileMode.Open, FileAccess.Read, FileShare.Read)
            ' do stuff here, details are not important
            fs.Close()
        End Using

        Return result
    End Function

I примите во внимание, что метод не показывает, как используется поток, но детали не имеют значения, как я объясню ниже.

Этот метод удобно размещен в библиотеке классов; Помощник , на который мы ссылаемся во множестве других проектов. Ясно, что по большей части этот код должен выглядеть нормально при условии, что путь действителен, доступен и т. Д.

Теперь проблема. У меня есть служебная библиотека WCF, которая ссылается и использует вышеупомянутый метод в сборке Helper . Библиотека службы WCF размещается в службе Windows, которая, в свою очередь, находится на одном из наших серверов.Служба WCF имеет операцию, которая получает UNC-путь для файла и во время обычного потока вызывает метод, указанный выше в вспомогательном классе.

Я отправляю путь для файла в общей папке в нашей сети. Строка «Использование fs как ...» завершается ошибкой со следующим исключением:

System.UnauthorizedAccessException: доступ к пути ', здесь указан путь к моему файлу »запрещен. в System.IO .__ Error.WinIOError (Int32 errorCode, String mightFullPath) в System.IO.FileStream.Init (строковый путь, режим FileMode, доступ к файлу, права Int32, логические права использования, общий ресурс FileShare, размер буфера Int32, параметры FileOptions, SECURITY_ATTRIBUTES secAttrs , String msgPath, Boolean bFromProxy, Boolean useLongPath) в System.IO.FileStream..ctor (строковый путь, режим FileMode, доступ к FileAccess, общий ресурс FileShare, размер буфера Int32, параметры FileOptions, String msgPath, логическое значение bFromProxy) в System.IO.FileStream ..ctor (String path, режим FileMode) в MyHelperAssemblyName.DoStuff (String filePath) в остальной частью исключения является трассировка стека, указывающая на метод, сборку, службу wcf и т. д. "

Теперь , список вещей, которые я пытался диагностировать (включая до глупости очевидные шаги):

• Скопируйте и вставьте путь, указанный в трассировке стека, в проводник Windows (как на моем локальном компьютере, так и на сервере), чтобы убедиться, что файл существует и доступен -> Возможность Доступ к файлу
• Убедитесь, что учетная запись службы Windows имеет достаточные права доступа к файлу для чтения -> Действующие разрешения перечисляет учетную запись службы как имеющую полный доступ
• Измените учетную запись службы Windows, чтобы использовать мою личную учетную запись администратора (временная мера) и, очевидно, перезапустите службу, чтобы изменения вступили в силу -> Та же строка кода не работает
• Скопируйте каталог, содержащий файл, на мою локальную машину и запустите службу на моем локальном компьютере (мы хотел убедиться, что NAS, на котором размещен файл, не был причиной) -> Та же строка кода не работает
• Создайте быстрое консольное приложение, скопируйте и вставьте код из метода вспомогательной сборки в приложение, введите тот же путь к файлу, запустите его локально, а затем на сервере (на сервере я имею в виду удаленное подключение к серверу, используя ту же учетную запись администратора, о которой я упоминал ранее, и запустите его) -> В приложении нет проблемы с запуском кода
• Создать консоль Application и используйте стандартный способ размещения библиотеки служб WCF в консольном приложении. Запустите приложение локально, а затем, используя WcfStorm для локального адреса, который я указал в качестве базового адреса для консольного приложения, вызовите тот же метод с тем же путем, что и обычная служба -> Результаты WcfStorm подтверждают, что с кодом не было проблем
• Дважды проверьте код библиотеки служб WCF, чтобы убедиться, что нет какой-либо специфической условной логики, которая могла бы повлиять на мои тесты -> Вспомогательный метод вызывается почти сразу после запуска реализации операции службы (сразу после проверки аргумента). Операция не может возвращать согласованные результаты без выполнения вспомогательного метода, поэтому, когда я получал согласованные результаты ранее и предполагал, что был запущен "странный" код доступа к файлу, он фактически был запущен
• развернул Службу с чистыми перестройками узла службы Windows, библиотеки службы WCF и сборки помощника (хотел убедиться, что код на моем экране фактически соответствует коду, который выполнялся на сервере) -> Без изменений
• РЕДАКТИРОВАТЬ 2011-06-24 16: 32GMT - Используя консольное приложение, которое я создал ранее для размещения службы WCF, соответствующим образом настройте baseAddress и разверните его на сервере. Запустите приложение, используя ту же учетную запись администратора, как указано выше. Протестируйте новое приложение на новом базовом адресе с помощью WcfStorm. -> Код работает так, как ожидалось, и дает хорошие результаты (я считаю, на данном этапе сужение его до ошибки службы Windows?)
• РЕДАКТИРОВАТЬ 2011-06-27 10: 21GMT - Создано простая служба Windows, ссылающаяся на вспомогательный класс. Установленная на сервере, учетная запись службы будет такой же, как у Live Server. -> Новая служба смогла запустить код и получить доступ к файлу

• РЕДАКТИРОВАТЬ 2011-06-27 10: 23GMT - Раздраженный тем, что служба сработала, я открыл WcfStorm, который я оставил пробег на выходных. Результаты представляли собой кадры с пятницы, показывающие, что служба в реальном времени не работает. Я повторно отправил тот же запрос -> Это сработало ... Сейчас меня больше раздражает, потому что у меня нет реальных средств отслеживания проблемы

  Итак, служба на данный момент работает правильно. У кого-нибудь есть идеи, что может вызвать такой периодический сбой? Коллеги уверили меня, что за выходные ничего не изменилось (по крайней мере, вручную). Озадаченный ...