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

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

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

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

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

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

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

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

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.

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

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

Я предполагаю, что другая сборка, которую вы используете, ссылается на старую dll. Вы знакомы со всеми другими используемыми ссылками на проекты, и есть ли в них ссылки на библиотеки DLL Telerik?

Можете ли вы поместить такое перенаправление привязки в свой файл web.config?

<dependentAssembly>
 <assemblyIdentity name="Telerik" publicKeyToken="121fae78165ba3d4"/>
 <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

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

Во-первых: я бы не стал устанавливать сборки ЛЮБОГО поставщика (например, telerik) в GAC. В любом случае материалы Telerik скомпилированы всего до двух сборок (telerik.web.design и telerik.web.ui). Просто разверните их вместе с приложением.

Во-вторых, в каждом из ваших файлов .proj (например, .csproj) должен быть <reference include..>значок, указывающий на файл Telerik.Web.UI. Обычно он содержит номер версии. Убедитесь, что сборка, которую вы поместили в папку bin, соответствует этой версии.

В-третьих, убедитесь, что ВСЕ ваши проекты используют последнюю сборку. Также убедитесь, что они захватывают сборку по локальному пути, а не из GAC. (Мне действительно не нравится GAC. Он вызвал бесконечные проблемы в некоторых проектах, над которыми я работал). Обычно у нас есть папка «Assemblies», которую все проекты используют для ссылок на внешние сборки.

В-четвертых, Visual Studio автоматически ищет ваш gac каждый раз при загрузке проекта веб-сайта и перенаправляет места сборки, если что-то находит в gac. Я не могу вспомнить, делал ли он это когда-либо для проектов веб-приложений, но у меня давно не было проблем с ними. Это может вызвать аналогичные проблемы во время развертывания.

В-пятых, вы можете повторно привязать номера версий для сборок в файле web.config. В этом runtime/assemblybindingразделе вы можете использовать что-то вроде следующего, которое переносит каждую сборку Telerik, развернутую в 2008 году, вперед и указывает на конкретную версию:

  <dependentAssembly>
    <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
    <bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0" newVersion="2010.02.0713.35" />
  </dependentAssembly>

Я попробовал большинство ответов, но все равно не смог заставить его работать. Это сработало для меня:

щелкните правой кнопкой мыши ссылку -> свойства -> измените значение «Определенная версия» на значение false.

Надеюсь это поможет.

Пытаться:

• очистка временных файлов проекта
• очистка файлов сборки и obj
• очистка старых версий, установленных на C:\Users\USERNAME\.nuget\packages\

Это сработало для меня.

1. Перейдите в C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG
2. Найдите файл machine.config
3. открыть в блокноте
4. найти конфликтную dll
5. Удалите это и сохраните.

сборки компиляции

addassembly = dllName, Version = 1.0.0000.0000 Культура = нейтральный, PublicKeyToken = "QWEWQERWETERY"

сборка сборок

работает для меня.

Это не ясный ответ, почему, но у нас была эта проблема, вот наши обстоятельства и то, что ее решило:

Dev 1:

Решение содержит проект A, ссылающийся на пакет NuGet, и проект MVC, ссылающийся на проект A. Включено восстановление пакета NuGet, а затем обновлен пакет NuGet. Получил ошибку во время выполнения, сообщающую, что библиотека NuGet не может быть найдена, но ошибка заключается в поиске более старой, не обновленной версии. Решение (и это нелепо): установите точку останова на первой строке кода в проекте MVC, который вызывает Project A. Введите F11. Решено - больше никогда не было проблем.

Dev 2:

То же решение и проекты, но волшебная точка останова и шаг в решении не работают. Искал повсюду перенаправления версий или другие плохие ссылки на этот пакет Nuget, удалил пакет и переустановил его, стер bin, obj, Asp.Net Temp, ничего не решило. Наконец, переименовал в Project A, запустил проект MVC - исправлено. Его переименовали обратно в исходное название, оно осталось неизменным.

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

Есть ли у вас какие-либо другие проекты в этом решении? (Может быть, другой проект ссылался на старую версию) Обычно в VS зависимость dll охватывает все проекты в решении.

Моя проблема заключалась в том, что старые сборки находились в папке _bin_deployableAssemblies в веб-приложении. Это означало, что старые сборки перезаписывали сборки GAC при сборке проекта.

В случае, если это спасет кого-то еще 3 часа ... мой случай был немного другим. В моем коде использовался DevExpress v11.1 v11.1.4.0. В моем коде все это было правильно указано. Но профилировщик памяти .net установил DevExpress v11.1 v11.1.12.0 в GAC. Фактически, это были не те компоненты, на которые я ссылался, а те, на которые они ссылались внутри себя. Как бы я ни старался, в первую очередь всегда проверяется GAC. Он компилировался и работал нормально, но я не мог видеть конструктор выигрышных форм, а трассировка стека не помогала. Наконец удалил профилировщик памяти .net, и все было восстановлено.

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

Если у вас возникла эта проблема при тестировании и / или отладке приложения из среды Visual Studio (ASP.NET Development Server), необходимо удалить все временные файлы в папке веб-сайта разработки. Чтобы узнать, где находится эта папка, найдите значок сервера разработки ASP.NET на значке в области уведомлений Windows (он должен иметь такой заголовок: Сервер разработки ASP.NET - порт ####), щелкните значок правой кнопкой мыши и выберите Показать Детали; thn, поле Physical path сообщит вам, что это за временная папка, все элементы в ней должны быть удалены, чтобы решить проблему. Создайте и снова запустите веб-сайт, и проблема должна быть решена (опять же, решена для среды разработки).

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

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

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

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

Я получал:

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

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

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

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

Итак, первое, что нужно проверить, - это версия указанной DLL в папке приложения. Так, на всякий случай.

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

В My Visual Studio 2015 я удостоверился, что список ссылочных путей проекта Visual Studio является пустым:

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

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

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

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

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

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

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

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

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