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

https://stackoverflow.com/questions/215026

03-07-2019
|

Вопрос

Я пытаюсь запустить некоторые модульные тесты в приложении C # Windows Forms (Visual Studio 2005) на C # и получаю следующую ошибку:

Исключение System.IO.FileLoadException:Не удалось загрузить файл или сборку "Утилита, версия = 1.2.0.200, Культура = нейтральная, PublicKeyToken=764d581291d764f7" или одну из ее зависимостей.Определение манифеста найденной сборки не соответствует ссылке на сборку.(Исключение из HRESULT:0x80131040)**

в x.Foo.FooGO()

в x.Foo.Foo2(строка 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-файла?

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

Решение

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

Другие советы

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

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

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

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

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

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

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

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

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

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

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

<Ол>

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

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

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

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

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

Get-Project -All | Add-BindingRedirect

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сначала, когда приложение было установлено, присутствующие здесь люди использовали в приложении Microsoft Enterprise Library 4.1.
На предыдущей неделе моя машина была отформатирована, и после этого сегодня, когда я создал это приложение, оно выдало мне сообщение об ошибке, что сборка Enterprise Library отсутствует.
Затем я установил Microsoft Enterprise Library 5.0, которую я получил в Google в качестве первой поисковой записи.
Затем, когда я создал приложение, оно выдало мне указанную выше ошибку, т.е.Определение манифеста найденной сборки не соответствует ссылке на сборку.
После большой части поисковой работы и анализа я обнаружил, что приложение ссылается на 4.1.0.0, а библиотека DLL в папке bin была версии 5.0.0.0
Затем я установил корпоративную библиотеку Microsoft 4.1.
Удалена предыдущая ссылка (5.0) и добавлена ссылка 4.0.
Создал приложение и voila...it заработало.

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

<Ол>

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

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

Хорошо, поэтому в этом примере мой .dll определенно равен 2.0.5022.0 (поэтому номер версии исключения указан неверно).

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow