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

Ответ 1

загрузчик .NET Assembly не может найти 1.2.0.203, но нашел 1.2.0.200. Эта сборка не соответствует запросам, и поэтому вы получаете эту ошибку. Говоря простыми словами, он не может найти ссылку на сборку. Убедитесь, что он может найти нужную сборку, поместив ее в GAC или в путь приложения. Также см. http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx.

Ответ 2

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

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

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

Ответ 3

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

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

Не удалось загрузить файл или сборку 'CompanyClasses, Version = 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), и эта ошибка ушла для меня.

Ответ 4

Следующий вариант перенаправляет любую версию сборки до версии 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) это не будет работать.

Ответ 5

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

Ответ 6

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

Ответ 7

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

Ответ 8

Я добавил пакет 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>

Ответ 9

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

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

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

Ответ 10

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

Ответ 11

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

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

Get-Project -All | Add-BindingRedirect

Ответ 12

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

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

Ответ 13

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

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

Ответ 14

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

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

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

Ответ 15

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

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

Ответ 16

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

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

Ответ 17

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

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

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

Ответ 18

Все вышеизложенное меня смутило, однако это спасло мой день: http://runtingsproper.blogspot.in/2010/04/solved-located-assemblys-manifest.html

Ответ 19

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

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

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

Ответ 20

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

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

Ответ 21

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

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

Ответ 22

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

Ответ 23

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

Ответ 24

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

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

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

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

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

Ответ 25

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

Ответ 26

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

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 manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

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

<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 для производственного сервера, вы должны объединить секцию dependAssembly в синхронизации после использования NuGet.

Ответ 27

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

• Сначала, когда приложение было установлено, люди здесь использовали 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.
• Построено приложение и вуаля... он работал.

Ответ 28

Здесь мой метод исправления этой проблемы.

• Из сообщения об ошибке получите имя библиотеки проблем и номер ожидаемой версии.

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" />

Задание выполнено!

Ответ 29

Если вы когда-нибудь получите сообщение об ошибке "Определенное определение манифеста сборки не соответствует ссылке на сборку", и если вы обновили страницу Project> Manage NuGet Packages и Update в VS, первое, что вы могли бы сделать, это попытаться установить другую версию пакет после проверки версий с страницы галереи NuGet и выполнения следующей команды из консоли диспетчера пакетов:

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

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

Ответ 30

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

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

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