Определение манифеста обнаруженной сборки не соответствует ссылке на сборку

Question

Я пытаюсь запустить некоторые модульные тесты в приложении C # Windows Forms (Visual Studio 2005) и получаю следующую ошибку:

System.IO.FileLoadException: Не удалось загрузить файл или сборку 'Утилита, Версия = 1.2.0.200, Культура = нейтральная, PublicKeyToken = 764d581291d764f7' или одна из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040) **

в x.Foo.FooGO ()

в x.Foo.Foo2 (String groupName_) в Foo.cs: строка 123

в x.Foo.UnitTests.FooTests.TestFoo () в FooTests.cs: строка 98 **

System.IO.FileLoadException: Не удалось загрузить файл или сборку 'Утилита, Версия = 1.2.0.203, Культура = нейтральная, PublicKeyToken = 764d581291d764f7' или одна из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

Я смотрю в своих ссылках, и у меня есть только ссылка на Utility version 1.2.0.203 (другая - старая).

Любые предложения о том, как я выясняю, что пытается ссылаться на эту старую версию этого DLL-файла?

Кроме того, я не думаю, что у меня даже есть эта старая сборка на моем жестком диске. Есть ли инструмент для поиска этой старой версионной сборки?

Answer 1

Щелкните правой кнопкой мыши ссылку в VS, установите для свойства «Конкретная версия» значение True.

Answer 2

На вопрос уже есть ответ, но если проблема возникла в пакете NuGet в разных версиях одного и того же решения, вы можете попробовать следующее.

Откройте диспетчер пакетов NuGet, поскольку вы видите, что версия моего сервисного проекта отличается от других.

Затем обновите проекты, содержащие старую версию вашего пакета.

Answer 3

ОК, еще один ответ. Ранее я создал свое приложение как 64-битное и изменил путь вывода (Project / Properties / Build / Output / Output Path) соответственно. Недавно я изменил приложение на 32 бит (x86), создав новый путь вывода. Я создал ярлык, куда я думал скомпилированный .exe. Независимо от того, что я изменил об источнике, он получил ошибку не совпадающую. Примерно через час разочарования я случайно проверил дату / время файла .exe и обнаружил, что он старый и явно ссылается на старый .dll. Я компилировал приложение в старый каталог, и мой ярлык ссылался на более новый. Изменил путь вывода, куда должен идти .exe , запустил ярлык, и ошибка исчезла. (шлепает по лбу)

Answer 4

Я столкнулся с той же проблемой при запуске своих юнит-тестов.

Ошибка ясно говорит о том, что проблема заключается в следующем: когда мы пытаемся загрузить сборку, загрузчик сборок .NET пытается загрузить свои упомянутые сборки на основе данных манифеста (упомянутое имя сборки, токен открытого ключа, версия).

Чтобы проверить данные манифеста:

1. Откройте командную строку Visual Studio,
2. Введите 'ildasm', перетащите нужную сборку в окно ILDASM и откройте представление MANIFEST. Иногда MANIFEST содержит одну сборку с двумя версиями старой версии, а также новую версию (например, Utility, Version=1.2.0.200 и Utility, Version=1.2.0.203). На самом деле упомянутая сборка Utility, Version=1.2.0.203(new version), но, поскольку манифест содержит даже Utility, Version=1.2.0.200(old version), загрузчик сборок .NET пытается найти этот версионный DLL-файл, не может найти его и выдает исключение.

Чтобы решить эту проблему, просто перетащите каждую из зависимых от проекта сборок в окно ILDASM отдельно и проверьте, какая зависимая сборка содержит данные манифеста со старой версией сборки. Просто пересоберите эту зависимую сборку и верните ее обратно в ваш проект.

Answer 5

Это также может произойти, если вы используете оба AssemblyInfo.cs с тегами AssemblyVersion и ваш файл .csproj имеет другое значение. При сопоставлении AssemblyInfo или удалении всего раздела проблема исчезает.

Answer 6

Эта же ошибка возникла у меня в моем проекте модульных тестов и привела к некоторым неудачным тестам. Я дважды проверил, какая версия сборки я использовал в проводнике сборок, и проверил содержимое тегов времени выполнения / зависимой сборки и понял, что на другую версию сборки, которую я использовал, все еще ссылаются. Поскольку это была единственная директива в моем тестовом проекте app.config, я просто попытался удалить весь файл app.config, перестроить решение, и это помогло! Больше нет ссылочных ошибок для меня:)

Answer 7

У меня была эта проблема после начала использования InstallShield. Несмотря на то, что в порядке сборки указывалось, что проект установки был последним, сборка вышла из строя.

Я исправил это, сделав каждый другой проект зависимым от него - это заставило установку собираться последней и тем самым устранило несоответствие моей сборки. Надеюсь, это поможет.

Answer 8

проверьте licenses.licx в свойствах проекта, там найдете неправильную версию .... у меня это работало в ссылках активного отчета

Answer 9

Была ли упомянутая проблема в этом посте "Любые предложения о том, как я выясняю, что пытается сослаться на эту старую версию этого DLL-файла?"

Нужно, какая сборка все еще ссылается на старый клиент ODATA 6.15.0, ildasm помог мне сузиться (без доступа к базовому коду, только через развернутый pkg на сервере).

Снимок экрана ниже для быстрой сводки.

DeveloperPackge, если нет ildasm.exe https://www.microsoft.com/net/download/visual-studio-sdks

Answer 10

Попробуйте добавить в глобальный кеш сборок все, чего не хватает.