.Net выбирает неправильную версию сборки

Question

Я просто скопировал существующий проект на совершенно новую машину, чтобы начать разработку на нем, и столкнулся с проблемой с версией одной из моих сборок, на которые есть ссылка (например, Telerik DLL).

Первоначально проект ссылался на старую версию сборки (назовем ее v1.0.0.0).На моей новой машине установлена ​​последняя версия сборки, поэтому я решил обновить ее (давайте назовем новую версию v2.0.0.0).

Теперь вот проблема: если я скопирую старую версию v1.0.0.0 dll в папку проекта и добавить его в качестве ссылки, веб-сайт запускается без проблем.Если я удаляю эту ссылку (а также удаляю старую DLL из моей системы) и добавляю новую версию (v2.0.0.0), на странице появляется следующее исключение:

Не удалось загрузить файл илисборка 'XXXXXX, версия = 1.0.0.0, культура = нейтральная, PublicKeyToken = 121fae78165ba3d4' или одна из ее зависимостей.Определение манифеста обнаруженной сборки не соответствует ссылке на сборку.(Исключение из HRESULT: 0x80131040)

Очевидно, что код ищет устаревшую версию и не может ее найти.Но почему?

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

Затем я включил просмотрщик журнала Fusion дляпопытайтесь выяснить, почему он ищет эту старую версию, но не повезло:

Assembly Load Trace: The following information can be helpful to determine why the assembly 'XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4' could not be loaded.


=== Pre-bind state information ===
LOG: User = MyComp\me
LOG: DisplayName = XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
 (Fully-specified)
LOG: Appbase = file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/
LOG: Initial PrivatePath = d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\bin
Calling assembly : WebApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX/XXXXXX.DLL.
LOG: Attempting download of new URL file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/bin/XXXXXX.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Все это говорит о том, что начинается с поиска этой старой сборки.Я попытался найти решение в Интернете и увидел этот ТАК вопрос , но, похоже, это полная противоположность моей проблеме.Программа этого спрашивающего находила не ту DLL, на которую ссылалась.В то время как моя проблема заключается в том, что программа таинственно ищет неправильную DLL и не может найти ее, когда нужную можно найти локально в папке bin и в GAC.

Почему мой ищет старую версию?Где еще я могу найти эту плохую ссылку?

Answer 1

Я получал:

Не удалось загрузить файл или сборку 'XXX-new-3.3.0.0' или одну из ее зависимостей. Определение манифеста обнаруженной сборки не соответствует ссылке на сборку. (Исключение из HRESULT: 0x80131040)

Это потому, что я изменил название сборки с XXX.dll на XXX-new-3.3.0.0.dll. Возврат имени к оригиналу исправил ошибку.

Answer 2

У меня была похожая проблема, и мне пришлось удалить все из папок bin и obj и пересобрать, чтобы обойти мою проблему. Надеюсь, это поможет.

Answer 3

У меня была одна и та же проблема с разными сборками, ссылающимися на разные версии Newtonsoft.json. Решение, которое работало для меня, - запуск пакета обновлений из консоли диспетчера пакетов Nuget.

Answer 4

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

Поэтому первое, что нужно проверить, - это версия библиотеки DLL, на которую есть ссылки, в папке приложения.На всякий случай.

Answer 5

В VS2017 перепробовал все вышеперечисленное решение, но ничего не работает.Мы используем разработчики Azure для управления версиями.

1. От проводника команд> Обозреватель контроля источников

Выберите проект, который вас долго сводит с ума

Щелкните правой кнопкой мыши ветку или решение> Дополнительно> получить конкретную версию

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

Answer 6

Эта ошибка несколько вводила в заблуждение - я загружал некоторые библиотеки DLL, для которых требовалось указать архитектуру x64. В файле .csproj:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release-ABC|AnyCPU'">
    <OutputPath>bin\Release-ABC</OutputPath>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

Отсутствие PlatformTarget вызвало эту ошибку.

Answer 7

В моем случае у меня было 3 проекта, 1 основной проект и 2 подпроекта, на которые ссылается основной проект. Итак, я обновил основной проект, оставив подпроект под своим контролемВот где был конфликт.После того, как я обновил весь свой проект, все заработало очень хорошо.

Answer 8

Это то, что сработало для меня:

Я использовал Microsoft.IdentityModel.Clients.ActiveDirectory версию 3.19 в проекте библиотеки классов, но в реальном проекте ASP.NET Web Application была установлена ​​только версия 2.22.Обновление до 3.19 в проекте веб-приложения помогло мне справиться с ошибкой.

Answer 9

В My Visual Studio 2015 я гарантировал, что список путей ссылок нарушающего проекта Visual Studio пуст:

Answer 10

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