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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Get-Project -All | Add-BindingRedirect

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

Answer 10

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

Answer 11

Возможно, у вас неправильные версии слепков в 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. Запустите ваше приложение и посмотрите, правильно ли оно работает. Если нет, добавьте любые отсутствующие перенаправления привязки, пропущенные консолью пакета.

Answer 12

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

Answer 13

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

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

Answer 14

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

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

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

Answer 15

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

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

Answer 16

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

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

Answer 17

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

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

Answer 18

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

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

Answer 19

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

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

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

Answer 20

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

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

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

Answer 21

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

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

Answer 22

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

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

Answer 23

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

Answer 24

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

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

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

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

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

Answer 25

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

Answer 26

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

Answer 27

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

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

Answer 28

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

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

Answer 29

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

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

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

Answer 30

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

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

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

Я упаковал пакеты nuget для всех проектов, использующих Yaml, с помощью задачи [email protected] :

       - 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>-tags в файлах *.csproj сборка / версия файла для dll была автоматически назначена переменной среды, и как nuget, так и dll (сборка / версия файла) будут иметь одинаковую версию, и проблема была решена.