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

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

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

я использую

Visual Studio Community 2013NUnit Adapter 3.4.0.0NUnit 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 но ссылаясь на 3.4.1 DLL.

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

 kurakura8803 авг. 2016 г., 10:24
Вы проверили, что файл существует и имеет временную метку времени, когда вы собираете / запускаете программу?
 Konstantin03 авг. 2016 г., 21:42
@ShakirAhamed: удалил ссылку и снова установил пакет. Нет успеха
 Konstantin03 авг. 2016 г., 21:48
Есть ли какая-либо информация, которую я могу предоставить, чтобы помочь выяснить источник проблемы?
 Konstantin08 авг. 2016 г., 20:52
Кто-нибудь знает, почему он не работает для сборок x64?
 Konstantin05 авг. 2016 г., 05:56
Я немного поэкспериментировал со всей настройкой. Я обнаружил, что если я собираю для x86, модульные тесты видны и могут быть выполнены. Но если я собираю для x64 dll, не загружается. Однако на моем другом проекте я строю для x64, и он работает просто отлично. Любые идеи, что я могу сделать, чтобы он работал на x64?
 Konstantin03 авг. 2016 г., 21:43
@RobProuse: нет, файлы не загружаются.
 Shakir Ahamed03 авг. 2016 г., 10:14
удалите папку bin и obj, перепакуйте ее и попробуйте запустить. это будет работать я думаю
 Konstantin05 авг. 2016 г., 06:05
Пожалуйста, также смотрите мой Edit # 1 в описании.
 Shakir Ahamed03 авг. 2016 г., 10:51
удалите ссылку Nunit из вашей справочной папки и установите ее снова, используя менеджер пакетов Install-Package NUnit Nuget
 Shakir Ahamed04 авг. 2016 г., 05:51
@Konstantin ты проверил этот вопрос, пожалуйста, обратитесь, это может помочь вамstackoverflow.com/questions/33240704/...
 Rob Prouse03 авг. 2016 г., 13:33
Пытались ли какие-либо из ваших тестов или тестируемый код загружать файлы или сборки? Если так, они принимают текущий каталог?
 Konstantin03 авг. 2016 г., 10:31
@ShakirAhamed, я удалил обе директории. Все еще не удается ...

Ответы на вопрос(5)

Решение Вопроса

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

 Konstantin26 авг. 2016 г., 05:57
Большое спасибо, что сработало! Знаете ли вы, в каком файле эта настройка сохраняется?
 Fishus26 авг. 2016 г., 11:29
К сожалению, не наверняка, однако, поскольку он меняется от решения к решению и не изменяется при переключении конфигураций, я подозреваю, что он будет частью файла suo.

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

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

Когда вы выбираете его из тестового меню (1), он будет добавлен как выбранный в меню (2), а после перестроения тест появится в Test Explorer (3).

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

 Konstantin06 сент. 2016 г., 05:54
Большое спасибо, это действительно делает его более стабильным.

у меня сработало следующее:

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

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

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

заметил основную причину, по которой один из зависимых dll отсутствовал для загрузки. Эта ошибка («NUnit не удалось загрузить DLL-файл») была показана в окне «Вывод» («Тест») после изменения кода метода теста и попытки его запустить. После обновления пакета nuget для зависимой dll nunit начал выбирать dll тестового проекта, и тестовые случаи выполнялись.

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

 user27664831 янв. 2019 г., 10:12
Вы могли бы использоватьInternalsVisibleToAttribute чтобы позволить вашей тестовой сборке получить доступ к внутренним компонентам.

Ваш ответ на вопрос