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

c# reference compiler-errors dependencies version

870443 просмотра

30 ответа

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

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

Автор: leora Источник Размещён: 23.05.2019 12:02

Ответы (30)


418 плюса

Решение

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

Автор: Lars Truijens Размещён: 18.10.2008 01:39

88 плюса

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

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

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

Автор: Seth Petry-Johnson Размещён: 20.10.2008 09:31

54 плюса

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

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

Автор: Nathan Bedford Размещён: 17.11.2009 07:15

50 плюса

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

Автор: Yaniv.H Размещён: 02.11.2012 12:34

38 плюса

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

Автор: Tad Размещён: 13.07.2010 03:27

30 плюса

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

Автор: RayLoveless Размещён: 28.06.2013 05:21

21 плюса

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

Автор: Neal Tibrewala Размещён: 03.09.2009 12:00

19 плюса

Я добавил пакет 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>
Автор: frattaro Размещён: 05.03.2014 04:22

14 плюса

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

Автор: Glade Mellor Размещён: 15.09.2010 05:07

14 плюса

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

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

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

Автор: Levi Fuller Размещён: 09.10.2016 06:34

8 плюса

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

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

Автор: Sire Размещён: 23.11.2009 11:09

8 плюса

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

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

Get-Project -All | Add-BindingRedirect
Автор: codeMonkey Размещён: 24.01.2019 07:27

5 плюса

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

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

Автор: Guy Starbuck Размещён: 16.07.2010 09:22

5 плюса

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

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

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

Автор: Bijimon Размещён: 08.08.2010 05:28

4 плюса

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

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

Автор: Mike Murphy Размещён: 13.03.2012 03:32

4 плюса

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

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

Автор: AEON Blue Software Размещён: 27.04.2012 11:20

4 плюса

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

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

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

Автор: Ben Pretorius Размещён: 28.06.2013 11:17

4 плюса

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

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

Автор: cederlof Размещён: 16.07.2015 08:28

4 плюса

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

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

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

Автор: Thomas Размещён: 01.10.2012 09:34

3 плюса

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

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

Автор: Ladislav Mrnka Размещён: 01.06.2012 01:07

3 плюса

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

Автор: uli78 Размещён: 04.03.2013 09:04

2 плюса

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

Автор: dhiraj1mumbai Размещён: 10.08.2017 04:15

2 плюса

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

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

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

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

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

Автор: Ganesh Londhe Размещён: 03.12.2017 06:39

1 плюс

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

Автор: rjain Размещён: 06.06.2014 09:27

1 плюс

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

  • Сначала, когда приложение было установлено, люди использовали 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.
  • Построил приложение и вуаля ... это работало.
Автор: user4846550 Размещён: 29.04.2015 01:10

1 плюс

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

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

введите описание изображения здесь

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

введите описание изображения здесь

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

  1. Найдите номер версии, который был показан в сообщении об исключении во всех файлах .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" />

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

Автор: Mike Gledhill Размещён: 15.11.2016 04:00

1 плюс

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

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.

Автор: Tomas Kubes Размещён: 07.12.2014 04:24

1 плюс

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

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

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

Автор: Jaggan_j Размещён: 15.06.2018 03:14

0 плюса

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

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

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

Автор: dan Размещён: 12.07.2011 02:24

0 плюса

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

Автор: DevXP Размещён: 30.07.2013 05:43
Вопросы из категории :
32x32