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

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

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

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

Answer 6

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

Answer 7

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

Answer 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>

Answer 9

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

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

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

Answer 10

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