.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

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

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

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

Answer 2

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

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

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

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

В-четвертых, 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>

Answer 3

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

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

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

Answer 4

Попробуйте:

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

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

Answer 5

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

Dev 1:

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

Dev 2:

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

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

Answer 6

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

сборочные сборки

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

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

у меня работает.

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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