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

Загрузчик сборки .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). Когда у вас есть список результатов, нажмите View-> Choose Details ... и затем отметьте «Версия файла». Это отобразит номер версии в списке результатов, чтобы вы могли видеть, откуда могла взяться старая версия.

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

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

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

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

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

Could not load file or assembly 'CompanyClasses, Version=1.4.1.0, Culture=neutral, PublicKeyToken=045746ba8544160c' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference

Проблема была в том, что в моей системе не было файлов 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), и эта ошибка исчезла для меня.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Откройте командную строку Visual Studio,
2. Введите «ildasm» и перетащите требуемую сборку в окно ILDASM и откройте представление МАНИФЕСТА. Иногда МАНИФЕСТ содержит одну сборку с двумя версиями: старая версия, а также новая версия (например, 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 отдельно и проверьте, какая зависимая сборка содержит данные манифеста со старой версией сборки. Просто перестройте эту зависимую сборку и верните ее в свой проект.

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

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

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

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

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

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

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

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

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

В моем решении было два проекта, назовем их «Клиент» и «Данные» - проект библиотеки классов, который содержал мои модели EF и контекст. Клиент сослался на проект данных.

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

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

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

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

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

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, и это не было бы проблемой. Кроме того, на моем локальном компьютере файл 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 для рабочего сервера, вам необходимо синхронизировать этот раздел зависимой сборки после использования NuGet.

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

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

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

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

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

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

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

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

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

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

Дело сделано !

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Снимок экрана ниже для краткого обзора.

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

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

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

Get-Project -All | Add-BindingRedirect

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

Я получал:

Could not load file or assembly 'XXX-new' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Это произошло потому, что я изменил название сборки с XXX.dll на XXX-new.dll. Возврат имени к исходному устранил ошибку.

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

Получилось у меня за System.ValueTuple

Unexpected Error Could not load file or assembly 'System.ValueTuple, Version=4.0.1.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' or one of its dependencies. The system cannot find the file specified.

Решил, установив .NET Framework 4.7.2 Runtime на машину, на которой произошла ошибка. Просто и не нужно добавлять bindingRedirect, изменять GAC или понижать пакеты NuGet и т. д.

https://dotnet.microsoft.com/download/dotnet-framework/net472

У меня не сработало ни одно решение. Я попробовал очистить проект, удалить корзину, обновить пакет, перейти на более раннюю версию и так далее ... Через два часа я загрузил 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>

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

Запустите код в отладчике Visual Studio. Пожалуйста, бегите, пока не получите исключение. Будет пользовательский интерфейс исключения Visual Studio. Пожалуйста, прочтите «Полная информация» / «Показать подробности» внизу Visual Studio Exception. В разделе Полные сведения / Показать подробности он сказал мне, что один из моих проектов (который относился к моему основному проекту, имеет другую версию Microsoft.IdentityModel.Clients.ActiveDirectory). В моем случае проект модульного тестирования вызывал мой проект. Мой проект модульного тестирования и мой проект имеют другую версию Microsoft.IdentityModel.Clients.ActiveDirectory. Я получаю ошибку во время выполнения, когда выполнялся мой модульный тест.

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

У меня была аналогичная проблема, но у меня ничего не получилось.

Решение, которое сработало для меня, заключалось в удалении части publicKeyToken из файла проекта (YourProject.csproj) вручную.

Раньше было:

<Reference Include = "Utility, Version=0.0.0.0, Culture=neutral, PublicKeyToken=e71b9933bfee3534, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

После изменения было:

<Reference Include = "Utility, Version=1.0.1.100, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

Убедитесь, что SpecificVersion - это False.

Решил мою проблему таким образом с помощью грубой силы.

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

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

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

Я удалил app.manifest в своем проекте / свойствах, и проблема была устранена. Это не включало упоминания о вызывающих нарушение ссылках DLL - поэтому я не знаю, почему это вызывало проблему.

Попробовав многие из вышеперечисленных решений без каких-либо исправлений, нужно было убедиться, что в вашем приложении в Visual Studio включен параметр «Автоматическое создание перенаправления привязки».

Более подробную информацию о включении автоматического перенаправления привязки можно найти здесь: https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/how-to-enable-and-disable-automatic-binding-redirection

Попробуйте удалить ссылку на сборку из своего веб-файла Config / appConfig.

 <dependentAssembly>
        <assemblyIdentity name = "System.IO" publicKeyToken = "B03F5F7F11D50A3A" culture = "neutral" />
        <bindingRedirect oldVersion = "0.0.0.0-4.1.2.0" newVersion = "4.3.0.0" />
      </dependentAssembly>

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

Единственный способ получить правильную информацию о версии - это проанализировать сам файл. Один из полезных инструментов - dotPeek. По моему опыту, имя сборки, указанное в dotPeek, всегда является точным.

Так, например, правильная привязка для этого файла следующая:

<dependentAssembly>
    <assemblyIdentity name = "System.ComponentModel.Annotations" publicKeyToken = "b03f5f7f11d50a3a" culture = "neutral"/>
    <bindingRedirect oldVersion = "0.0.0.0-4.2.1.0" newVersion = "4.2.1.0"/>
</dependentAssembly>

Проводник Windows говорит, что это файл 4.6.26515.06, nuget говорит, что это файл 5.0.0.0. dotPeek говорит, что это 4.2.1.0, и это версия, которая корректно работает в нашем программном обеспечении. Также обратите внимание, что открытый ключ и культура важны, и dotPeek также показывает эту информацию.

Это довольно старый вопрос, и недавно у меня было такое же сообщение об ошибке с конвейерами Azure DevOps Yaml и Dotnet Core 3.1. Проблема была несколько иной, чем другие ответы, которые пытаются решить, поэтому я поделюсь своим решением.

У меня было решение со многими проектами для моих собственных пакетов nuget. Я случайно добавил тег версии в файлы * .csproj, например:

  <Project Sdk = "Microsoft.NET.Sdk">
  <PropertyGroup>
    <Version>1.0.0</Version>
  </PropertyGroup>

Я упаковал пакеты nuget для всех проектов, использующих Yaml, с помощью задачи DotnetCoreCLI @ 2:

 - task: DotNetCoreCLI@2
   displayName: 'pack'
   inputs:
     command: pack
     nobuild: true
     configurationToPack: 'Release'
     includesource: true
     includesymbols: true
     packagesToPack: 'MyNugetProject1.csproj;**/MyNugetProject2.csproj'
     versioningScheme: 'byEnvVar'
     versionEnvVar: 'GitVersion.SemVer'

Проблема заключалась в том, что версия в файлах * .csproj не соответствовала версии в переменной среды GitVersion.SemVer (заданной параметром input- «versionEnvVar»).

После удаления всех тегов <Version>1.0.0</Version> в файлах * .csproj сборка / версия файла для dll была автоматически назначена переменной среды, и как nuget, так и dll (сборка / версия файла) имели одинаковую версию, и проблема была решена.

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

Для меня это исправило изменение версии пакета на версию, запрошенную в ошибке.

Пакет был в netstandard 2.1, а проект, запрашивающий пакет, был в netcore 3.1.

Возможно, у вас неправильные версии слепков в assemblyBinding попробуйте:

1. Удалите все содержимое привязки сборки в web.config / app.config:

<assemblyBinding xmlns = "urn:schemas-microsoft-com:asm.v1">
  <dependentAssembly>
    <assemblyIdentity name = "Microsoft.Extensions.Logging.Abstractions" publicKeyToken = "adb9793829ddae60" culture = "neutral" />
    <bindingRedirect oldVersion = "0.0.0.0-3.1.3.0" newVersion = "3.1.3.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name = "Microsoft.Extensions.DependencyInjection" publicKeyToken = "adb9793829ddae60" culture = "neutral" />
    <bindingRedirect oldVersion = "0.0.0.0-3.1.3.0" newVersion = "3.1.3.0" />
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name = "System.ComponentModel.Annotations" publicKeyToken = "b03f5f7f11d50a3a" culture = "neutral" />
    <bindingRedirect oldVersion = "0.0.0.0-4.2.1.0" newVersion = "4.2.1.0" />
  </dependentAssembly>
</assemblyBinding>

2. Введите в консоли диспетчера пакетов: Add-BindingRedirect.
3. Сгенерированы все необходимые переадресации привязки
4. Запустите ваше приложение и посмотрите, правильно ли оно работает. Если нет, добавьте любые отсутствующие перенаправления привязки, пропущенные консолью пакета.