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

Я пытаюсь запустить некоторые модульные тесты в приложении 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-файла?

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

Загрузчик сборки .NET:

• не может найти 1.2.0.203
• но нашел 1.2.0.200

Эта сборка не соответствует тому, что было запрошено, и поэтому вы получаете эту ошибку.

Проще говоря, он не может найти сборку, на которую ссылались. Убедитесь, что он может найти правильную сборку, поместив ее в GAC или в путь приложения. Также см. Https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference .

Вы можете сделать несколько вещей, чтобы устранить эту проблему. Во-первых, используйте поиск файлов Windows для поиска вашего жесткого диска для вашей сборки (.dll). Получив список результатов, выполните Вид-> Выбрать подробности ..., а затем установите флажок «Версия файла». Это отобразит номер версии в списке результатов, так что вы сможете увидеть, откуда может исходить старая версия.

Кроме того, как сказал Ларс, проверьте ваш GAC, чтобы увидеть, какая версия там указана. В этой статье Microsoft говорится, что сборки, найденные в GAC, не копируются локально во время сборки, поэтому вам может потребоваться удалить старую версию перед выполнением перестройки всех. (См. Мой ответ на этот вопрос для заметок о создании командного файла, чтобы сделать это для вас)

Если вы все еще не можете определить, откуда взялась старая версия, вы можете использовать приложение fuslogvw.exe, поставляемое с Visual Studio, для получения дополнительной информации об ошибках привязки. У Microsoft есть информация об этом инструменте здесь . Обратите внимание, что вам нужно включить ведение журнала, установив для параметра HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogреестра значение 1.

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

У меня было две библиотеки DLL, на которые ссылался мой основной проект: CompanyClasses.dll и CompanyControls.dll. Я получал ошибку во время выполнения, говоря:

Не удалось загрузить файл или сборку 'CompanyClasses, версия = 1.4.1.0, Culture = нейтральный, PublicKeyToken = 045746ba8544160c' или одна из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку

Проблема была в том, что в моей системе не было файлов CompanyClasses.dll с номером версии 1.4.1. Ни в GAC, ни в папках приложений ... нигде. Я искал весь мой жесткий диск. Все файлы CompanyClasses.dll, которые у меня были, были 1.4.2.

Реальная проблема, которую я обнаружил, заключалась в том, что CompanyControls.dll ссылался на версию 1.4.1 CompanyClasses.dll. Я просто перекомпилировал CompanyControls.dll (после ссылки на CompanyClasses.dll 1.4.2), и эта ошибка исчезла для меня.

Следующее перенаправляет любую версию сборки на версию 3.1.0.0. У нас есть скрипт, который всегда будет обновлять эту ссылку в App.config, поэтому нам больше никогда не придется заниматься этой проблемой.

С помощью отражения вы можете получить сборку publicKeyToken и сгенерировать этот блок из самого файла .dll.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

Обратите внимание, что без атрибута пространства имен XML (xmlns) это не будет работать.

Если вы используете Visual Studio, попробуйте «чистое решение», а затем пересоберите свой проект.

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

Я только что столкнулся с этой проблемой, и проблема была в том, что у меня была старая копия .dll в моем каталоге отладки приложения. Вы можете также проверить там (вместо GAC), чтобы увидеть, видите ли вы это.

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

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

Get-Project -All | Add-BindingRedirect

Я добавил пакет NuGet только для того, чтобы понять, что часть моего приложения в «черном ящике» ссылается на более старую версию библиотеки.

Я удалил пакет и сослался на статический файл DLL старой версии, но файл web.config никогда не обновлялся из:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

к чему он должен был вернуться при удалении пакета:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

В моем случае эта ошибка произошла при запуске приложения ASP.NET. Решением было:

1. Удалите objи binпапки в папке проекта

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

В моем случае это была старая версия библиотеки DLL в каталоге C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporary ASP.NET Files \. Вы можете удалить или заменить старую версию, или вы можете удалить и добавить ссылку на DLL в вашем проекте. По сути, в любом случае будет создан новый указатель на временные файлы ASP.NET.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Я просто нашел другую причину, почему получить эту ошибку. Я очистил свой GAC от всех версий определенной библиотеки и построил свой проект со ссылкой на конкретную версию, развернутую вместе с исполняемым файлом. Когда я запускаю проект, я получаю это исключение в поисках более новой версии библиотеки.

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

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

Простое удаление содержимого папки bin вашего проекта и перестроение решения решило мою проблему.

очистить и перестроить решение может не заменить все библиотеки DLL из выходного каталога.

я предлагаю переименовать папку из «bin» в «oldbin» или из «obj» в «oldobj»

а затем попробуйте снова построить свой силуэт.

incase, если вы используете какие-либо сторонние dll-файлы, которые вам нужно будет скопировать во вновь созданную папку "bin" или "obj" после успешной сборки.

надеюсь, что это будет работать для вас.

Вручную может помочь удаление старой сборки из папки и добавление ссылки на новые сборки.

Я получил ту же ошибку ... В моем случае это было решено следующим образом:

• Сначала, когда приложение было установлено, тогда люди использовали Microsoft Enterprise Library 4.1 в приложении.
• На предыдущей неделе мой компьютер был отформатирован, и после этого сегодня, когда я создавал это приложение, он выдал ошибку, что сборка Enterprise Library отсутствует.
• Затем я установил Microsoft Enterprise Library 5.0, которую я получил в Google в качестве первой поисковой записи.
• Затем, когда я построил приложение, он дал мне вышеуказанную ошибку, т.е. определение манифеста расположенной сборки не соответствует ссылке на сборку.
• После значительной части поисковой работы и анализа я обнаружил, что приложение ссылалось на 4.1.0.0, а DLL в папке bin была версии 5.0.0.0.
• Затем я установил Microsoft Enterprise Library 4.1.
• Удалена предыдущая ссылка (5.0) и добавлена ​​ссылка 4.0.
• Построил приложение и вуаля ... это работало.

Вот мой метод решения этой проблемы.

1. Из сообщения об исключении получите имя «проблемной» библиотеки и «ожидаемый» номер версии.

2. Найдите все копии этого .dll в вашем решении, щелкните правой кнопкой мыши по ним и проверьте, какая версия .dll это.

Итак, в этом примере мой .dll определенно равен 2.0.5022.0 (поэтому номер версии Exception неверен).

3. Найдите номер версии, который был показан в сообщении об исключении во всех файлах .csproj в вашем решении. Замените этот номер версии на фактический номер из DLL.

Итак, в этом примере я бы заменил это ...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... с этим...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Работа выполнена !

В моем случае проблема была между стулом и клавиатурой :-)

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

Две или более разных сборок хотели использовать другую версию библиотеки DotNetOpenAuth, и это не было бы проблемой. Кроме того, на моем локальном компьютере NuGet автоматически обновляет web.config:

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

Затем я понял, что забыл скопировать / развернуть новый файл web.config на рабочем сервере. Поэтому, если у вас есть способ ручного развертывания web.config, убедитесь, что он обновлен. Если у вас совершенно другой файл web.config для производственного сервера, вы должны синхронизировать этот раздел зависимых сборок после использования NuGet.

Если вы когда-нибудь получите ошибку вроде " Определение манифеста обнаруженной сборки не соответствует ссылке на сборку », и если вы обновились через « Проект»> «Управление пакетами NuGet и вкладка« Обновление »в VS» , первое, что вы можете сделать, это попробовать установить другую версию пакет после проверки версий со страницы галереи NuGet и запуска следующей команды из консоли диспетчера пакетов:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Хотя ответ не имеет прямого отношения к рассматриваемому пакету и его спросили еще в обратном направлении, он носит общий характер, все еще актуален и надеется, что он кому-то поможет.

Ни одно решение не сработало для меня. Я попытался очистить решение проекта, удалить bin, пакет обновления, пакет downgrade и т. Д. Через два часа я загрузил App.config по умолчанию из проекта со сборками и там я изменил неверную эталонную версию с:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

чтобы:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

После этого я очистил проект, собрал его снова, и он заработал. Нет предупреждения, нет проблем.

Я получил это сообщение об ошибке из-за ссылки на сборку с тем же именем, что и сборка, которую я собирал.

Это скомпилировано, но оно перезаписало ссылочную сборку текущей сборкой проектов, что вызвало ошибку.

Чтобы исправить это, я изменил название проекта и свойства сборки, доступные при щелчке правой кнопкой мыши по проекту и выборе «Свойства».