Не удалось загрузить файл или сборку Assembly.dll - vstest

У меня такая ошибка при запуске одного модульного теста: Тестовый метод TestName вызвал исключение: System.IO.FileNotFoundException: не удалось загрузить файл или сборку Assembly.dll или одну из ее зависимостей. Указанный модуль не может быть найден.

Эта проблема возникает только при использовании vstest.console.exe. Этого не происходит, когда я запускаю свой тест через Visual Studio (2013). Я знаю, что vstest.executionengine.exe запускается при запуске тестов через Visual Studio. Журналы для него можно включить в файле vstest.executionengine.exe.config (но он не дает мне никакой полезной информации).

Я уже использовал Dependency Walker, как предлагалось во многих других вопросах такого типа:  Dependency Walker screenshot И я вижу, что все библиотеки DLL окрашены в красный цвет в каталоге System32 или в каталоге выполнения программы (Dependency walker думает что они отсутствуют). Выполнение тестов выглядит так:

«C: \ Program Files (x86) \ Microsoft Visual Studio 12.0 \ Common7 \ IDE \ CommonExtensions \ Microsoft \ TestWindow \ vstest.console.exe» «dll1.dll» «dll2.dll» (и т. Д. Для всех dll с тестами) / InIsolation / UseVsixExtensions: false / Platform: x86 / Framework: framework40 / Logger: trx / Tests: TestName (и все возможные отсутствующие библиотеки DLL, только не API-MS-WIN (...) именованные библиотеки DLL находятся в каталоге TestWindow или System32) . Я уже проверял. У меня установлен распространяемый компонент Microsoft Visual C ++ 2008, 2010, 2012 и 2013 как в версии x86, так и в версии x64. Изменилось название отсутствующей dll и название теста, естественно у них другие названия :)


person Zygmuntix    schedule 14.09.2016    source источник
comment
Вы пробовали вести журнал привязки сборки? Убедитесь, что vstest.console.exe запускается из того же места и использует то же PATH в своей среде. Вы можете записать командную строку / среду успешного vstest.executionengine.exe с помощью Process Explorer.   -  person Jeroen Mostert    schedule 15.09.2016
comment
Извини, что ответил так поздно. Это было так, как вы думали, Джероен Мостерт :) Переменная PATH была еще одной для двух сред, которые я использовал. Одного каталога не было в PATH, и из-за этого не удалось найти DLL. Я узнал об этом в четверг, но тогда я не опубликовал ответ.   -  person Zygmuntix    schedule 19.09.2016


Ответы (1)


После расследования: переменная PATH была другой для двух сред, которые я использовал. Одного каталога не было в переменной среды PATH, и из-за этого не удалось найти DLL. Добавление этого ключевого каталога в переменную PATH решило проблему. Средой с неполной переменной PATH был Jenkins.

person Zygmuntix    schedule 19.09.2016