HRESULT: 0x80131040: определение манифеста обнаруженной сборки не соответствует ссылке на сборку - PullRequest
Новая
       57

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

51 голосов
/ 18 сентября 2008

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

получить это при запуске nunit через ncover. Есть идеи?

Ответы [ 18 ]

45 голосов
/ 18 сентября 2008

Это несоответствие между сборками: DLL, на которую ссылается сборка, не имеет ожидаемой сигнатуры метода.

Очистите решение, восстановите все и попробуйте снова.

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

9 голосов
/ 10 сентября 2009

Недавно у меня возникла эта проблема, и я запустил файл "зависящий от.exe" для рассматриваемой библиотеки DLL. Он показал мне, что dll была скомпилирована в x86, а некоторые зависимости были скомпилированы в x64.

Если у вас все еще есть проблемы, я бы порекомендовал использовать зависящий от вас файл.exe.

7 голосов
/ 08 октября 2013

В моем случае для проекта wcf rest services мне пришлось добавить секцию времени выполнения в web.config, где был запрошенный dll: 

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" />
        <bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
      </dependentAssembly>
.
.
.
  <runtime>
6 голосов
/ 30 июля 2013

Это обычно происходит, когда версия одной из DLL среды тестирования не соответствует среде разработки.

Очистите и постройте свое решение и перенесите все свои библиотеки DLL в среду, где происходит ошибка, которая должна ее исправить

4 голосов
/ 06 ноября 2013

Я столкнулся с похожими проблемами при доступе к файлам проекта с разных компьютеров через общую папку. В моем случае clean + reabuild не помогло. Пришлось удалить папки bin и объектов из выходного каталога.

3 голосов
/ 02 февраля 2018

В моем случае я получил это сообщение во время отладки: 

"Error while calling service <ServiceName> Could not load file or assembly 'RestSharp, 
Version=105.2.3.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. 
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)"

Причина

В моем проекте было 2 внутренних компонента, использующих RestSharp, но оба компонента имеют разные версии RestSharp (один с версией 105.2.3.0, а другой с версией 106.2.1.0).

Решение

Либо обновите один из компонентов до более нового, либо понизьте рейтинг другого. В моем случае было безопаснее понизить рейтинг с 106.2.1.0 до 105.2.3.0, а затем обновить компонент в диспетчере пакетов NuGet. Таким образом, оба компонента имеют одинаковую версию.

Перестройте, и это сработало без проблем.

3 голосов
/ 30 августа 2015

Мои проблемы решены путем удаления всей части времени выполнения 

<runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="System.Web.Helpers" publicKeyToken="31bf3856ad364e35"/>
                <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35"/>
                <bindingRedirect oldVersion="1.0.0.0-3.0.0.0" newVersion="3.0.0.0"/>
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
2 голосов
/ 04 декабря 2011

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

Итак, если вы работаете с видимыми классами COM, убедитесь, что вы удалили более старые версии вашей сборки из GAC, прежде чем регистрировать новую сборку в RegASM.

1 голос
/ 14 января 2015

Я столкнулся с этой проблемой в проекте веб-API.

В проекте Api использовался пакет nuget библиотеки с версией 3. И одна из упомянутых сборок говорит, что X использовал более старую версию того же пакета nuget с версией 2.

При сборке ссылочной сборки или перестройке любого другого проекта, ссылающегося на X, сборки проекта api обновляются до более низкой версии. И получил эту ссылку ссылки на сборку.

Восстановление работает, но в моем случае я хотел найти долгосрочное решение.

Я сделал сборку со ссылкой на ту же версию пакета nuget.

1 голос
/ 09 декабря 2014

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

<dependentAssembly>
    <assemblyIdentity name="WebGrease" culture="neutral" publicKeyToken="31bf3856ad364e35" />
    <bindingRedirect oldVersion="0.0.0.0-1.6.5135.21930" newVersion="1.6.5135.21930" />
</dependentAssembly>

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

Страница:
...