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

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

668 голосов
/ 18 октября 2008

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

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

Ответы [ 46 ]

3 голосов
/ 01 июня 2012

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

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

2 голосов
/ 10 августа 2017

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

2 голосов
/ 03 декабря 2017

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

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

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

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

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

1 голос
/ 15 июня 2018

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

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

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

1 голос
/ 06 июня 2014

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

1 голос
/ 15 ноября 2016

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

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

enter image description here

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

enter image description here

Хорошо, в этом примере мой .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" />

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

1 голос
/ 29 апреля 2015

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

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

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

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.

0 голосов
/ 10 января 2018

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

0 голосов
/ 06 сентября 2012

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

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

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

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