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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Считайте "полное изложение" в Visual Studio. В Полном изложении это сказало мне, что один из моего проекта (то, которое обращалось к моему основному проекту, имеет другую версию Microsoft. IdentityModel. Клиенты. ActiveDirectory). В моем случае мой проект модульного теста называл мой проект. Мой проект модульного теста и мой проект имеют другую версию Microsoft. IdentityModel. Клиенты. ActiveDirectory. Я получаю ошибку периода выполнения, когда мой модульный тест выполнялся.

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

Никакое решение не работало на меня. Я попробовал чистое решение проекта, удалите мусорное ведро, обновите пакет, понизьте пакет и так далее... После двух часов я загрузил App.config по умолчанию из проекта с блоками, и там я изменил неправильную ссылочную версию от:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

к:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

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

У меня была подобная проблема, но никакой ответ не работал на меня.

решение, которое работало на меня, удаляло publicKeyToken часть из файла проекта (YourProject.csproj) вручную.

Ранее это было:

<Reference Include="Utility, Version=0.0.0.0, Culture=neutral, PublicKeyToken=e71b9933bfee3534, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

После изменения это было:

<Reference Include="Utility, Version=1.0.1.100, Culture=neutral, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>dlls\Utility.dll</HintPath>
</Reference>

Быть уверенным, что SpecificVersion False.

Решенный моя проблема как это с грубой силой.

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

Вошел в решение в проводнике, искал оскорбление DLL и удалил всех их. Затем добавленный ссылки на DLL назад с помощью одной версии DLL.

Попробуйте добавить недостающее в глобальный кеш сборок.

Щелкните правой кнопкой мыши ссылку в VS, установите для свойства «Конкретная версия» значение «Истина».