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

вы можете сделать несколько вещей, чтобы устранить эту проблему. Во-первых, используйте Windows File search для поиска жесткого диска для сборки (.файл DLL.) После того, как у вас есть список результатов, сделайте вид->выберите детали... а затем проверьте "версия файла". Это отобразит номер версии в списке результатов, чтобы вы могли видеть, откуда может исходить старая версия.

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

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

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

У меня было две библиотеки DLL, на которые ссылался мой основной проект: CompanyClasses.dll и CompanyControls.файл DLL. Я получал ошибку времени выполнения, говоря:

не удалось загрузить файл или сборку 'CompanyClasses, Версия=1.4.1.0, Культура=нейтральный, 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. У нас есть скрипт, который всегда будет обновлять эту ссылку в приложении.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-файл старой версии, но в интернете.файл конфигурации никогда не обновлялся из:

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

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

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

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

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

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

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

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

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

моя ситуация была очень похожа на сообщение Натана Бедфорда, но с небольшим поворотом. Мой проект также ссылался на измененную dll двумя способами. 1) напрямую и 2) косвенно, ссылаясь на компонент (библиотеку классов), который сам имел ссылку на измененную dll. Теперь мой проект Visual studio для компонента (2) ссылается на правильную версию измененной dll. Однако номер версии самого compnent не был изменен. И в результате установка новой версии project не удалось заменить этот компонент на клиентском компьютере.

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

разрешение: удалить приложение; удалить все библиотеки DLL из папки приложения; переустановить.В моем случае все просто.

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

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

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

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

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

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

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

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

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

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

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

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

Мои приложения.config содержит

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

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

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

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

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

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

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

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

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

• сначала, когда приложение было установлено, то люди здесь использовали Microsoft Enterprise Library 4.1 в приложении.
• на прошлой неделе моя машина была отформатирована и после этого сегодня, когда я построил это приложение, то он дал мне ошибку, что сборка библиотеки предприятия отсутствует.
• затем я установил 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. из сообщения об исключении получите имя библиотеки" проблема "и" ожидаемый " номер версии.

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

Итак, в этом примере, мой .библиотека DLL определенно 2.0.5022.0 (поэтому номер версии исключения неверен).

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

работу !

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

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

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:

<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, проверьте его обновляемый. Если у вас совершенно другая сеть.config для производственного сервера необходимо объединить эти разделы dependentAssembly в синхронизации после использования NuGet.

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

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

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

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

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

У меня была та же проблема сегодня, которая помешала мне выполнить Add-Migration после внесения изменений в Entity Framework.

У меня было два проекта в моем решении, назовем их "клиент" и "данные" - проект библиотеки классов, который содержал мои модели EF и контекст. Клиент ссылается на проект данных.

Я подписал оба проекта,а затем внес изменения в модель EF. После того, как я удалил подпись, я смог добавить миграции, а затем подписал проект заново.

Я надеюсь, что это может быть полезно для кого-то, избавляя их от длительного разочарования..