Подтвердить что ты не робот

NUnit не удалось загрузить DLL

При попытке запуска модульных тестов в Visual Studio появляется следующее сообщение об ошибке:

NUnit failed to load w:\Repos\trading.tools\Trading.Tools.Test\bin\x64\Debug\Trading.Tools.Test.dll

Я использую

  • Сообщество Visual Studio 2013
  • NUnit Adapter 3.4.0.0
  • NUnit 3.4.1

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

Я также загрузил NUnit 3.4.1 и установил его. Когда я запустил

nunit3-console.exe Trading.Tools.Test.dll

все работает отлично. Любые идеи, что я могу сделать?

Большое спасибо Константин

Изменить # 1

Вот полный вывод консоли из Visual Studio при попытке выполнить все тесты.

Test run will use DLL(s) built for framework Framework45 and platform X86. Following DLL(s) will not be part of run: 
Trading.Tools.Test.dll, Trading.Tools.dll are built for Framework Framework45 and Platform X64.
 Go to http://go.microsoft.com/fwlink/?LinkID=236877&clcid=0x409 for more details on managing these settings.
NUnit Adapter 3.4.0.0: Test discovery starting
NUnit failed to load w:\Repos\trading.tools\Trading.Tools.Test\bin\x64\Debug\Trading.Tools.Test.dll
Assembly contains no NUnit 3.0 tests: w:\Repos\trading.tools\Trading.Tools\bin\x64\Debug\Trading.Tools.dll
NUnit Adapter 3.4.0.0: Test discovery complete

Как вы можете видеть, очень очевидно, что NUnit ожидает сборку x86, но я создаю для платформы x64. И снова моя сборка x64 прекрасно работает, если я ее выполнил с помощью nunit3-console.exe.

Что я вижу в файле csproj:

<Reference Include="nunit.framework, Version=2.6.4.14350, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\packages\NUnit.3.4.1\lib\net45\nunit.framework.dll</HintPath>
</Reference>

Странно то, что он указывает использование Version=2.6.4.14350, но ссылается на dll 3.4.1.

Итак, следующий вопрос из этого момента - как я могу сделать NUnit для выполнения моей сборки x64? Любые идеи?

4b9b3361

Ответ 1

У меня была похожая проблема, ключевой момент в том, что именно Test Runner в Visual Studio утверждает, что будут протестированы только сборки x86. Исходя из этого, я предполагаю, что он заставляет использовать бегун x86 NUnit. Чтобы изменить это (по крайней мере, в VS2015 и VS2017), Test Settings Test > " Test Settings > " Default Processor Architecture > " X64.

Ответ 2

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

введите описание изображения здесь

Чтобы включить его, сделайте, как показано на рисунке ниже:

введите описание изображения здесь

Когда вы выберете его из тестового меню (1), оно будет добавлено как выбранное в меню (2), и после этого Rebuild сделает тест в Проводнике тестеров (3)

Существует дополнительный бонус с использованием файла runsettings, и это значит, что он будет работать правильно в системе сборки TFS, если вы используете это. Я написал сообщение в блоге по этой проблеме, см. http://hermit.no/how-to-control-the-selection-of-test-runner-in-tfsvsts-making-it-work-with-x86x64-selected-targets/

Ответ 3

Мне удалось получить эту ошибку при написании метода unit test. И заметила основную причину отсутствия одной из зависимых dll для загрузки. Эта ошибка ( "NUnit не удалось загрузить .dll" ) была показана в окне "Выход" ( "Тест" ) после изменения кода метода тестирования и попытки его запуска. После обновления пакета nuget для зависимой dll nunit начал собирать DLL тестового проекта, и тестовые случаи были выполнены.

Ответ 4

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

Ответ 5

После неудачной попытки всех остальных ответов выше, у меня сработало следующее:

В моем случае проект и решение .NET находятся на смонтированном диске (я использую MacBook и Parallels для разработки .NET). Монтирование также содержит местоположения /bin/debug и /bin/release, из которых NUnit пытался прочитать "тестовую" DLL.

Исправление было в том, чтобы переместить файлы решения/проекта на диск C: моего образа Windows. Испытания были обнаружены немедленно.

Видимо, общее/смонтированное местоположение было не по душе. Я не знаю почему, так как монтирование является постоянным и доступно для чтения/записи всем пользователям образа Windows. Я подозреваю, что проблемы с правами доступа к файлам или, возможно, каким-то образом все монтирование не доступно пользователю/процессу, выполняющему логику обнаружения NUnit.