Модульные тесты Visual Studio генерируют MissingMethodException, когда сборка находится в GAC? - PullRequest
1 голос
/ 14 октября 2008

Мое приложение содержит фрагмент кода, который выполняется внутри Служб компонентов, поэтому нам необходимо зарегистрировать наш слой бизнес-правил (и его зависимости) в GAC. Одной из таких зависимостей является FooCore.dll, которая содержит классы и службы, видимые для всего приложения.

Все работало нормально, пока я не добавил новый метод в класс в FooCore. Теперь, когда я запускаю свои модульные тесты, любой тест, который вызывает этот новый метод, генерирует исключение MissingMethodException, даже если я обновляю GAC последней версией сборки. Единственное исправление - удалить FooCore из GAC перед запуском тестов.

Я пробовал следующие вещи:

  • Перестроил все решение, обновил содержимое в GAC, затем запустил тесты = сбой
  • Удалено и повторно добавлено руководство по сборке FooCore в тестовом проекте = ошибка
  • Гарантировано, что FooCore установлен как "Копировать локальный" в свойствах = ошибка

Что я могу сделать, чтобы VSTS загружал ссылочные сборки из их явно определенного расположения, а не из GAC?

Ответы [ 2 ]

1 голос
/ 14 октября 2008

Дальнейшее исследование обнаружило эту ветку форума по этому вопросу , в которой кто-то предполагает, что это может быть вызвано тем, что функция Performance Analysis VS2008 держит устаревшую версию сборки.

Я смог решить мою проблему:

  1. Перестройте моё решение, затем
  2. Обновление всего в GAC, затем
  3. Удаление и повторное добавление ссылок на сборки в моем тестовом проекте, затем
  4. Закрытие и повторное открытие Visual Studio 2008

Я не уверен, какой из этих шагов был явно необходим, но этот подход "кухонная раковина" решил проблему для меня.

Обновление: В этой статье Microsoft говорится, что при компиляции решения сборки, найденные в GAC, никогда не копируются в папку bin вывода \, даже если для параметра «Копировать локально» задано значение true.

0 голосов
/ 23 ноября 2015

В моем случае у меня было две одинаковые (почти) сборки в разных местах. Протестированный проект был связан с первой сборкой, а проект UnitTest - со второй (они были абсолютно одинаковыми).

Так что внимательно проверяйте все ссылки на проекты.

...