.Net вибір неправильної посилальної версії збірки


141

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

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

Тепер ось проблема: Якщо я скопіюю старий d1 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.

Все це говорить, що це починається з пошуку тієї старої збірки. Я спробував знайти рішення в Інтернеті і побачив це подібне питання ТА , але, здається, якраз протилежний моїй проблемі. Програма того, хто запитував, знаходив неправильну DLL замість посилальної. Тоді як моя проблема полягає в тому, що програма загадково шукає неправильну DLL і не може її знайти, коли потрібну можна знайти локально в папці bin та в GAC.

Чому мій шукає стару версію? Де ще я можу шукати, щоб знайти цю погану довідку?

Відповіді:


151

Я думаю, що інша збірка, яку ви використовуєте, посилається на старий dll. Чи знайомі ви з усіма іншими посиланнями на проекти, які використовуються, і чи є одна з них посиланням на осередки Telerik?

Чи можете ви помістити перенаправлення обов'язкового файлу у свій файл web.config таким чином?

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

12
У мене були всілякі проблеми, подібні до цієї, з різними версіями завантаження / не завантаження. Ще один трюк, який ви можете спробувати, - це видалити всі файли у вашій C: /WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files / root / 90233b18 / 10d54998. Іноді під час перекомпіляції веб-сайтів ASP.Net не очищає цю папку через деякі блокування файлів, і вони можуть зависати до старих посилань. Варто зняти, я знаю, що це працювало для мене в минулому.
Кріс Конвей

1
Ви вирішили пов’язану для мене проблему - дякую! Успадкована форма в моєму додатку C # не відкрилася в дизайнері, оскільки вона шукала стару версію посилання. Виявляється, інша посилання була створена спочатку, посилаючись на цю стару версію посилання на проблему.
Сем Скуче

2
Якщо ви блукаєте
Junior Mayhé

1
Дякую Крис! Ви вирішили тут мою проблему: stackoverflow.com/q/11490177/7850
Shaul Behr

3
Ви також можете заглянути у свій App.config або web.config і побачити, чи є існуючі <dependentAssembly>записи причиною проблеми.
Рой Тінкер

24

Я з Крісом Конвеєм на цьому (підтримав його). Проблема полягає в тому, що ви посилаєтесь на одну із збірок telerik у своєму проекті, яка посилається на іншу, яку там немає.

Перше: я не встановлював би будь-яких постачальницьких (тобто: telerik) зборок у GAC. Робота Telerik складається в будь-якому випадку лише на дві збірки (telerik.web.design та telerik.web.ui). Просто розгорніть їх із додатком.

По-друге, у кожному з ваших .proj-файлів (наприклад, .csproj) <reference include..>міститься файл, який вказує на файл Telerik.Web.UI. Зазвичай він містить номер версії. Переконайтесь, що збірка, яку ви помістили у папку бін, відповідає цій версії.

По-третє, переконайтеся, що ВСІ ваші проекти використовують останню збірку. Також переконайтеся, що вони захоплюють збірку з місцевого шляху замість 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>

2
Я мав на увазі "відчуваю", це мене турбує вже місяці :)
Майкл Ла Вой

21

Я спробував більшість відповідей, але все-таки не зміг змусити його працювати. Це працювало для мене:

клацніть правою кнопкою миші посилання -> властивості -> змініть "Конкретну версію" на помилкову.

введіть тут опис зображення

Сподіваюся, що це допомагає.


30
Ось що означає голосування +1.
xr280xr

7
Але іноді простий підсумок просто недостатньо підсумовує, наскільки щаслива та полегшена відповідь робить вас - після того, як ви витратили години та години на те, щоб виправити тупу проблему, яка навіть не повинна бути проблемою, і ви намагаєтеся гуглювати її по-іншому. , натрапи на іншу відповідь, ніж ти раніше, і бум! це працює зараз! Зрештою, інколи просто натискання кнопки оновлення не справляється з цим непосильним почуттям, чувак, ти насправді визволив мене з цього.
Майкл Плаут

7

Спробуйте:

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

Це працювало для мене.


1
Очищення каталогу C: \ Users \ USERNAME \ .nuget \ пакети \ було те, чого я бракував. Дуже дякую!
Гердо

для чистої старої версії nuget, на комп'ютері на базі Windows, запустіть ckuck і знайдіть "запустити"> скопіювати та вставте "% userprofile% \. nuget \ пакети" - це відкриє папку з версією
ногет

3
  1. Перейдіть до C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG
  2. Знайдіть файл machine.config
  3. відкрити в блокноті
  4. знайти конфлікт dll
  5. Видаліть це і збережіть.

складання збірок

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

складання збірок

працює для мене.


2
Я також виявив цей кошмар - навіть якщо ви видалите збірки з GAC залишає неправильні посилання версії в «C: \ Windows \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG \ machine.config»
Евалдс Уртанс

3

Це не однозначна відповідь, чому, але у нас виникла ця проблема, ось наші обставини і що її вирішило:

Dev 1:

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

Dev 2:

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

Я не маю жодних пояснень, чому це спрацювало, але це нас вирвало з серйозних причин.


2

Чи є у вас інші проекти в цьому рішенні? (Можливо, інший проект посилався на стару версію) Зазвичай у VS залежність від dll охоплює всі проекти в рішенні.


Жодних інших проектів у вирішенні та жодних інших посилань на DLL, що посилаються на telerik. Я лише посилаюся на MS DLLs ala System. *
Michael La Voie

2

Моя проблема полягала в тому, що старі збірки знаходилися в папці _bin_deployableAssemblies під веб-додатком. Це означало, що старі збірки перезаписували збірки GAC під час створення проекту.


2

У випадку, якщо економиться хтось інший 3 години ... мій випадок був дещо іншим. Мій код використовував DevExpress v11.1 v11.1.4.0. У мене все це було правильно вказано в коді. Але. Net Profiler встановив DevExpress v11.1 v11.1.12.0 в GAC. Насправді це не ті компоненти, на які я посилався, а ті, на які вони посилалися всередині, не вдалися. Спробуйте, як я міг, GAC завжди спочатку перевіряється. Він склав і пройшов чудово, але я не міг переглянути дизайнера форм виграшів, і слід стека зовсім не допомагав. Нарешті вилучив .net-пам'ять. І все було відновлено.


2

У мене була подібна проблема, і мені довелося видалити все з папок bin та obj і відновити її, щоб пройти проблему. Сподіваюся, це допомагає.


1

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


1

У мене виникли однакові проблеми з різними збірками, що посилаються на різні версії Newtonsoft.json. Для мене працювало рішення - запускати оновлення-пакет від консолі Nuget Package Manager.


1

Ця помилка була дещо оманливою - я завантажував деякі DLL-файли, які потребували уточнення архітектури x64. У .csprojфайлі:

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

Відсутність PlatformTargetспричинила цю помилку.


1

Я отримував:

Не вдалося завантажити файл або збірку "XXX-new-3.3.0.0" або одну з її залежностей. Маніфестне визначення розташованої збірки не відповідає посиланням на збірку. (Виняток з HRESULT: 0x80131040)

Це було тому, що я змінив назву асамблеї з XXX.dllна XXX-new-3.3.0.0.dll. Повернення імені до оригіналу виправлено помилку.


Так - включена версія в ім’я в нашій загальній бібліотеці збірок, щоб уникнути проблем з називанням у керуванні джерелами. Змінено ім'я назад і вручну оновило довідники / підказки, і все це спрацювало.
Mathew Paxinos

0

Це майже як ви повинні витерти комп'ютер, щоб позбутися від старого DLL. Я вже спробував усе вище, і тоді я пішов на додатковий крок - просто видалити кожен екземпляр файлу .DLL, який знаходився на моєму комп’ютері, і видалити всі посилання з програми. Однак він все ще компілюється просто добре, і коли він працює, він посилається на функції dll просто добре. Я починаю цікавитись, чи посилається вона з мережевого накопичувача.


0

У мене було те саме повідомлення при переключенні між двома версіями програми, що посилалися на різні версії однієї DLL. Хоча я тестував у різних папках, я випадково скопіював нову версію на старішу.

Отже, перше, що потрібно перевірити, це версія посилається на DLL у папці програми. Про всяк випадок.


0

Можливо, це допомагає, а може ні. Я очистив версії налагодження та версії, тоді я перейменував папку OBJ. Це нарешті мене розігнало. Попередні кроки були, головним чином, видаленням проектів посилань та додаванням їх у властивості проекту.


0

У «Моїй візуальній студії 2015» я переконався, що список довідників Проекту Visual Studio Список пустих порожній:

введіть тут опис зображення


Ви опублікували таку саму відповідь на 2 різні запитання?
AK47

0

Це для мене працювало:

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


0

У моєму випадку у мене було 3 проекти, 1 головний проект та 2 підпроекти, на які посилався головний проект. Тож я оновив основний проект, не виходячи з підпроекту. Ось тут і був конфлікт. Після того як я оновив весь свій проект, все працювало чудово.


0

У VS2017 випробували все вищезазначене рішення, але нічого не працює. Для версій ми використовуємо Azure devops.

  1. З команд Explorer> Провідник управління джерелами

введіть тут опис зображення

  1. Виберіть проект, який надовго наштовхує вас

  2. Клацніть правою кнопкою миші гілку чи рішення> Додатково> отримати конкретну версію

введіть тут опис зображення

  1. Потім переконайтесь, що ви поставили галочку для перезапису файлів відповідно до екрана

введіть тут опис зображення


0

У моєму випадку я випадково вибрав неправильну версію пакету Telerik з nuget, який потім замінив кожен пакунок, на який я посилався, на неправильну версію. Потім він вставив перенаправлення прив’язки до неправильної версії, так що навіть після того, як я замінив усе правильною версією, він все ще шукав неправильну версію.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.