Что может быть причиной исключения System.TypeLoadException в Visual Studio Unit Test?

Ответ 1

Узел MyClassLibrary был настроен на режим x86 в диспетчере конфигурации. Изменение этого параметра на x64 исправило его. Я действительно хочу, чтобы Visual Studio обнаружила это и сообщила о нем как о менее неясной ошибке.

Ответ 2

Я просто ударил головой об этом один час. Проблема заключалась в том, что у меня был проект командной строки с именем Something.exe, в котором использовался проект библиотеки классов с именем Something.dll.

Ответ 3

Случилось и со мной. В моем случае проблема возникла из-за того, что проект с тестируемым проектом и проектными модулями имел одно и то же имя. Если это ваш случай, переименуйте один из проектов и переименуйте имя выходного файла, чтобы исправить его.

Ответ 4

Случилось и со мной. Это связано с построением для режима x64, Release и x86. В моем случае я удалил папки в моем ящике (debug/release/x86 в сборках ссылок и unit test) и перезапустил мой unit test. VS2010 несколько сообщил об ошибке в окне вывода. Это решило это для меня.

Ответ 5

Прошел через это сегодня, и хотя я оставил бы свое исправление.

Характеристики: VS 2013/.NET 4.0

Решение: войдите в Меню > Тест > Настройки тестирования > Архитектура процессора по умолчанию > X64

Ответ 6

То же сообщение здесь, но я тоже не смог отладить тест.

В моем случае тестируемая DLL-библиотека была развернута в GAC (требование BizTalk). Я создал новый класс и тестировал его, но не с GAC'd с DLL с момента добавления тестируемого класса.

Ответ 7

У меня была аналогичная проблема с Trey, но вместо BizTalk у меня есть решение SharePoint, которое также использует развертывание GAC. У GAC была более старая сборка. Когда я удалил сборку GAC, втянув решение, тест прошел.

Ответ 8

У меня была эта ошибка с использованием NUnit 3 в VS 2013. Я решил ее, удалив ссылку на сборку в моем тестовом проекте для сборки, которая содержала тип, который не был найден, а затем повторно добавил ссылку.

Ответ 9

В случае, если это помогает другим с той же ошибкой (я понимаю, что он напрямую не отвечает на вопрос re Release vs Debug); Я объединился в проекте с прежним пространством, который противоречил существующему, и переименовал его. Я получил эту ошибку при попытке создать форму из этого проекта.

Я проверил, что цель платформы была одинаковой, и удалил.\bin\каталоги, чтобы обеспечить чистую перестройку, удалил ссылку на объединенный проект и повторно добавил его, но все равно ту же ошибку.

В конце концов (!) я проверил имя сборки в свойствах проекта (щелкните правой кнопкой мыши по проекту, выберите "свойства", выберите вкладку "Приложение" ) и измените его на соответствие пространству имен по умолчанию, и теперь все хорошо.

Ответ 10

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

Мое главное название проекта: Calculator.OperationsManager мое имя тестового проекта: Calculator.OperationsManager

Я изменил название тестового проекта как Calculator.OperationsManager.Test и все прошло хорошо.

Ответ 11

На всякий случай кому-то это нужно: я создал тестовый проект в Visual Studio и задался вопросом, почему некоторые классы не могут быть найдены, даже если Visual Studio неоднократно просила меня добавить "System.Web" в качестве ссылки.

Я сделал это, и ошибка продолжалась. Проблема для меня была простой (и я должен был проверить это раньше, я знаю): я создал тестовый проект из шаблона, который создал проект.NET Core. После изменения его на.NET Framework 4.6.1 и добавления "System.Web" в качестве ссылки все работало нормально.

Ответ 12

Столкнулся с той же проблемой. На всякий случай, если это кому-нибудь поможет - мне удалось заставить его работать, понизив пакет nuget NUnit3TestAdapter с версии 3.13.0 до 3.11.2.

Вы можете найти больше информации об этом - https://github.com/nunit/nunit-console/issues/424