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

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

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

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

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

У меня было две библиотеки 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), и эта ошибка ушла для меня.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Get-Project -All | Add-BindingRedirect

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

Если вы когда-нибудь получите сообщение об ошибке "Определенное определение манифеста сборки не соответствует ссылке на сборку", и если вы обновили страницу 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

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

Проблема со мной состояла в том, что в новой сборке были удалены старые dll, которые были удалены. Чтобы исправить это, я просто установил флажок для удаления дополнительных файлов в месте назначения при публикации. Удаление дополнительных файлов в пункте назначения

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

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

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

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

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

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

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

У меня была такая же проблема сегодня, что помешало мне выполнить Add-Migration после внесения изменений в Entity Framework.

У меня было два проекта в моем решении, позвоните им "Клиент" и "Данные" - проект библиотеки классов, в котором хранятся мои модели и контекст EF. Клиент ссылался на проект данных.

Я подписал оба проекта, а затем внес изменения в EF-модель. После того, как я удалил подпись, я смог добавить миграции, а затем мог бы снова подписаться на проект.

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

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

В вашей AssemblyVersion в файле AssemblyInfo.cs используйте номер фиксированной версии вместо указания *. * Будет изменен номер версии на каждой компиляции. Это было проблемой для этого исключения в моем случае.

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

В этой ошибке явно указано, что проблема заключается в следующем: когда мы пытаемся загрузить сборку, сборщик сборок.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 отдельно и проверьте, какая зависимая сборка содержит данные манифеста со старой версией сборки. Просто перестройте эту зависимую сборку и верните ее в свой проект.

У меня была аналогичная проблема при попытке обновить один DLL файл моего веб-сайта.

Эта ошибка произошла, когда я просто скопировал этот DLL файл в папку bin по FTP.

Я решил эту проблему:

1. остановка веб-сайта;
2. копирование необходимых файлов DLL/DLL;
3. начало веб-сайта

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

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

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

Щелкните правой кнопкой мыши ссылку в VS, установите свойство "Специфическая версия" на "Истина".

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