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

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

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

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

Не удалось загрузить файл или сборку 'XXXXXX, Version = 1.0.0.0, Culture = нейтрально, 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.

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

Ответ 1

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

Можете ли вы добавить переадресацию привязки в свой файл web.config следующим образом?

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

Ответ 2

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

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

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

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

В-четвертых, визуальная студия автоматически ищет ваш 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>

Ответ 3

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

щелкните правой кнопкой мыши по ссылке → свойства → измените "Специфическая версия" на false.

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

Ответ 4

Попробуйте:

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

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

Ответ 5

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

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

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

сборка сборников

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

Ответ 6

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

Dev 1:

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

Dev 2:

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

Ответ 11

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

Ответ 12

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

Ответ 13

Я получаю:

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

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

Ответ 14

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

Ответ 15

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

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

Ответ 16

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

Ответ 17

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

Ответ 18

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

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

Ответ 19

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

Ответ 20

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

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

Отсутствующая PlatformTarget причиной этой ошибки.

Ответ 21

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

Из командного проводника> Source Control Explorer

Выбери проект, который тебя долго сводит с ума
Щелкните правой кнопкой мыши ветку или решение> Дополнительно>, чтобы получить конкретную версию

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

Ответ 22

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