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

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

Я собираюсь взорвать умы всех прямо сейчас. , .

Удалите все ссылки <assemblyBinding> из файла .config, а затем выполните эту команду из консоли диспетчера пакетов NuGet:

Get-Project -All | Add-BindingRedirect

Answer 2

Для нас проблема была вызвана чем-то другим. Файл лицензии для компонентов DevExpress включал две строки, одна для старой версии компонентов, которые не были установлены на данном компьютере. Удаление более старой версии из файла лицензии решило проблему.

Раздражает то, что в сообщении об ошибке не указано, какая ссылка вызывала проблемы.

Answer 3

Моя была очень похожа на пост Натана Бедфорда, но с небольшим поворотом. Мой проект тоже ссылался на измененную dll двумя способами. 1) Непосредственно и 2) Косвенно путем ссылки на компонент (библиотеку классов), который сам имел ссылку на измененную DLL. Теперь мой проект Visual Studio для компонента (2) ссылался на правильную версию измененной библиотеки DLL. Однако номер версии самого компонента НЕ был изменен. В результате установка новой версии проекта не смогла заменить этот компонент на клиентском компьютере.

Конечный результат: Прямая ссылка (1) и Косвенная ссылка (2) указывали на разные версии измененной библиотеки DLL на клиентском компьютере. На моей машине разработчика все работало нормально.

Разрешение: удалить приложение; Удалить все DLLS из папки приложения; Переустановите. Просто в моем случае.

Answer 4

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

Вам необходимо добавить правильный токен открытого ключа (вы можете получить его, используя sn -T на dll), чтобы устранить ошибку. Надеюсь, это поможет.

Answer 5

Я позволю кому-нибудь извлечь выгоду из моей глупости. У меня есть некоторые зависимости от совершенно отдельного приложения (назовем это App1). DLL из этого App1 втянуты в мое новое приложение (App2). Каждый раз, когда я делаю обновления в APP1, я должен создавать новые библиотеки DLL и копировать их в App2. Что ж. , . Я устал от копирования и вставки между двумя разными версиями App1, поэтому я просто добавил префикс 'NEW_' к DLL.

Хорошо. , , Я предполагаю, что процесс сборки сканирует папку / bin, и когда он совпадает с чем-то неправильно, он выдает то же сообщение об ошибке, что и выше. Я удалил свои "новые_" версии, и он был построен просто денди.

Answer 6

Я получил эту ошибку при сборке на сервисе сборки Team Foundation Server. Оказалось, что в моем решении было несколько проектов с использованием разных версий одной и той же библиотеки, добавленной с NuGet. Я удалил все старые версии с NuGet и добавил новую как справочную для всех.

Team Foundation Server помещает все DLL-файлы в один каталог, и одновременно может быть только один DLL-файл с определенным именем.

Answer 7

Мой app.config содержит

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

для npgsql. Каким-то образом на компьютере пользователя пропал мой app.exe.config. Я не уверен, что это был глупый пользователь, сбой установщика или антивирус. Замена файла решила проблему.

Answer 8

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

Ничего из того, что я сделал, исправило ошибку, поэтому в спешке я вообще удалил каталог BIN. Восстановил мой исходный код, и с тех пор он работал.

Answer 9

Я хотел бы просто добавить, что я создавал базовый проект ASP.NET MVC 4 и добавил DotNetOpenAuth.AspNet через NuGet. Это привело к той же ошибке после того, как я сослался на несовпадающий файл DLL для Microsoft.Web.WebPages.OAuth.

Чтобы исправить это, я сделал Update-Package и очистил решение для полной перестройки.

Это сработало для меня и довольно лениво, но время - деньги: -P

Answer 10

Для меня конфигурация покрытия кода в файле "Local.testtesttings" "вызвала" проблему. Я забыл обновить файлы, на которые есть ссылки.