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

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

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

 Mostlyharmless18 сент. 2008 г., 18:01
Возможно, вы захотите немного изменить название и вопрос, чтобы привлечь больше глазных яблок. Что-то вроде «Я пытаюсь сделать X, и я получаю эту ошибку: {описание ошибки} ... и т. Д.
 Sami24 сент. 2015 г., 10:25
Старый поток, но общая проблема. Причиной для меня было то, что по какой-то причине у меня было 2 экземпляра Visual Studio, в которых работало одно и то же решение. Другой не был виден на панели задач, но только в диспетчере задач. Закрыл оба, потом чистая и восстановленная работала.
 MacGyver29 апр. 2015 г., 16:21
Хорошо, я мог найти этот вопрос по коду ошибки.

Ответы на вопрос(16)

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

когда версия одной из библиотек среды тестирования не соответствует среде разработки.

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

секцию времени выполнения в 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>

и я запустил «зависящий от файла» на dll, о котором идет речь. Это показало мне, что dll была скомпилирована в x86, а некоторые зависимости были скомпилированы в x64.

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

 RenniePet25 апр. 2011 г., 02:37
Там также Depends.Net,netomatix.com/development/DependsNet.aspx Моя проблема была банальной, module1 хотел загрузить module2 версии 5.0.0.0, а module2 фактически был 5.0.8.3760. Depends не пометил это, а Depends.Net сделал.

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

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

ней версии (используя 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 соответственно.

udio, -Microsoft.VisualStudio.TemplateWizardInterface - (после попытки установить странные инструменты разработки)

рассмотреть это решение (любезно предоставлено larocha (спасибо, кто бы вы ни были)):

Откройте C: \ Program Files \ Microsoft Visual Studio 9.0 \ Common7 \ IDE \ devenv.exe.config в текстовом редакторе.Найдите эту строку: "Microsoft.VisualStudio.TemplateWizardInterfacе»Закомментируйте элемент, чтобы он выглядел так:

<dependentAssembly><br><!-- assemblyIdentity name="Microsoft.VisualStudio.TemplateWizardInterface" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" / --><br><bindingRedirect oldVersion="0.0.0.0-8.9.9.9" newVersion="9.0.0.0" /><br></dependentAssembly>

источник:http://webclientguidance.codeplex.com/workitem/15444

g Assistant при первой десериализации XML-файла в объекты в VS2010 / .NET 4. DLL-библиотека, содержащая классы для объектов, генерируется в событии после сборки (обычные вещи в стиле Microsoft). Очень хорошо сработало несколько проектов в одном решении, проблема возникла при выполнении этого в еще одном проекте. Текст ошибки:

Обнаружена ошибка привязки. Сообщение: не удалось загрузить сборку с отображаемым именем MyProjectName.XmlSerializers в контексте привязки «LoadFrom» для AppDomain с идентификатором 1. Причина ошибки: System.IO.FileLoadException: Не удалось загрузить файл или сборку. MyProjectName.XmlSerializers, версия = 1.0.0.0, культура = нейтральная, PublicKeyToken = null 'или одна из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

Поскольку некоторые ответы здесь предполагали несоответствие платформы, я заметил, что для 3 проектов и решения выбрана конфигурация «смешанных платформ», и 3 проекта были скомпилированы для x86 вместо AnyCPU. У меня нет специфичного для платформы кода (хотя некоторые предоставляемые вендором библиотеки DLL используют несколько библиотек x86). Я заменил все вхождения x86 в AnyCPU следующим образом:

for a in $( egrep '(x86|AnyCPU)' */*.csproj *.sln -l  ) ; do echo $a ; sed -i 's/x86/AnyCPU/' $a ; done

Затем проект будет построен, но все параметры для запуска или отладки кода будут недоступны. Перезапуск VS не помог бы.

Я вернул git ссылки на библиотеку x86, на всякий случай, но сохранил AnyCPU для всего кода, который я компилирую.

СледующийF5 или кнопка «Начать отладку» неактивна для приложения Winform? Я выгрузил и перезагрузил стартовый проект (это был тот, где изначально возникла первоначальная проблема).

После этого все стало на свои места: программа работает без первоначальной ошибки.

Видетьhttp://www.catb.org/jargon/html/R/rain-dance.html , http://www.catb.org/jargon/html/V/voodoo-programming.html или жеhttp://www.catb.org/jargon/html/I/incantation.html и ссылки там.

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

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

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

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

когда он не мог найти сборку PayPal, и это было потому, что я назвал свое решение PayPal. Я уверен, что это не будет ответом ни для кого, но думал, что я поделюсь этим в любом случае:C # ASP.NET MVC PayPal не находит сборки

когда я обновил web.config, не обновляя все упомянутые dll.

Используя правильный diff-фильтр (остерегайтесь фильтра сравнения по умолчанию каталога Meld, игнорируя двоичные файлы), была обнаружена разница, файлы были скопированы, и все работало нормально.

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

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

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

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

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

 Maslow25 июн. 2009 г., 18:57
Есть ли способ заставить компилятор проверять такие вещи во время компиляции? Я мог поклясться, что это было по умолчанию в VS2005.

Просто проверьте ваш файл webconfig и удалите этот код: -

<dependentAssembly>
    <assemblyIdentity name="itextsharp" publicKeyToken="8354ae6d2174ddca" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.13.0" newVersion="5.5.13.0" />
  </dependentAssembly>

но за последние пару дней «обновился» до 2017 года. Решение было закрыть и снова открыть VS.

Это может быть связано с ошибкой, о которой я уже писалв другом месте, где не работает справочный менеджер? В этой ситуации появляется следующее сообщение об ошибке при попытке добавить ссылку в обозревателе решений:

Msgstr "Ошибка HRESULT E_FAIL возвращена при вызове COM-компонента."

Мой обходной путь - закрыть решение, снова открыть в VS2012, добавить ссылку, закрыть 2012 и открыть 2017. Смешно, что 2017-й должен был быть выпущен с такой очевидной ошибкой.

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

"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. Таким образом, оба компонента имеют одинаковую версию.

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

Ваш ответ на вопрос