0

Я задаю этот вопрос, прежде чем я узнаю полный ответ ради сообщества. Не стесняйтесь звонить в с предложениями и т.д.System.Data.OleDB.OleDBExeption (0x80004005): Ошибка создания файла при попытке доступа к файлу .xlsx из SharePoint

Сценарий:

Я работаю, чтобы создать автоматизированные тесты для клиента. Они хотели, чтобы эти тесты использовали источник данных, но хотели, чтобы они были обновлены ручными тестерами и сотрудниками, не программирующими, если это возможно. Решение, в которое мы приземлились, включает в себя таблицу, расположенную на сайте SharePoint, с строкой соединения, указанной в app.config. Программное обеспечение также определяет, какие параметры теста используются в Microsoft Test Manager (или если его отлаживают/запускают локально), и использует эту информацию для определения того, какие листы/строки ему нужны. Это решение работало безупречно локально.

Проблема:

Мы толкнули новую сборку и связанные с ними наши тестовые случаи с раствором. Я попытался запустить тесты из MTM. Первоначально тесты не выполнялись, потому что у тестового агента не было пакета excel или пакета подключения драйверов данных. Я исправил эту проблему и был представлен с тем, что вы видите в названии:

«System.Data.OleDB.OleDBExeption (0x80004005): Сбой при создании файла»

Это было смешно ошибка, потому что а) мы никогда не создать файл excel или даже писать ему. b) мы никогда не сталкивались с этой ошибкой при запуске локально, а учетная запись, используемая тестовым агентом, имела одинаковые разрешения sharepoint. Следует отметить, что агент Тест ВМ работает Server 2012.

Вот некоторые подсказки, что-то неладное:

  • Я мог просматривать сайт SharePoint и даже скачать файл данных испытаний .xlsx с использованием Internet Explorer при удалении в тестовый агент.
  • Однако я не смог открыть сайт SharePoint с помощью проводника Windows. Я получил сообщение об ошибке «У нас возникла проблема с открытием этого места в Проводнике. Добавьте этот веб-сайт в список доверенных сайтов и повторите попытку». Эта ошибка сохранялась даже после добавления сайта в доверенные сайты и обеспечения того, чтобы сервер был обновлен с помощью патчей. (Есть некоторые статьи в статье, посвященные этой проблеме)
  • Я также не мог сопоставить сетевой диск с сайт SharePoint, как у меня на моей машине dev

Наконец-то я попробовал что-то, что у меня было бы гораздо раньше. Я изменил строку подключения в app.config на локальное расположение файла (что-то вроде «C: /Folder/TestData.xlsx»), поставил в очередь новую сборку, загрузил тестовые данные из SharePoint и поместил ее в это место на тесте Агент. В результате тесты выполнялись правильно с использованием этого локального файла.

Если кто-то знает, как эта учетная запись AD может быть владельцем сайта SharePoint, но не может получить к ней доступ через проводник Windows, просьба дать ответ ниже, и вы получите некоторую SO-карму. В противном случае я отвечу, когда решит проблему.

ответ

1

Так исправить эту проблему сделал пару шагов:

  • Включено «Desktop Experience Feature» на агента тестирования VM.
  • Это добавило услугу «WebClient» для виртуальной машины.Мы запускаем эту службу автоматически.
  • Мы также пошли дальше и сопоставили диск SharePoint на машине. Я НЕ считаю, что это необходимо.
  • Служба WebClient упомянута в разделе устранения неполадок в статье THIS. Я расстроен тем, что не стал проверять эту услугу, и я не уверен, почему я это сделал.
Смежные вопросы