Помилка CS1705: "яка має вищу версію порівняно з посиланням"

Я трохи зараз розглядаю це питання і не встиг вирішити це. Я отримую таке повідомлення про помилку:

Compiler Error Message: CS1705: Assembly 'My.Model, Version=1.1.4422.23773, Culture=neutral, 
PublicKeyToken=bfde95ba233094b2' uses 
'Common, Version=3.3.4273.24368, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 
which has a higher version than referenced assembly
'Common, Version=3.3.4269.17112, Culture=neutral, PublicKeyToken=bfde95ba233094b2'

c:\WINDOWS\assembly\GAC_MSIL\Common\3.3.4269.17112__bfde95ba233094b2\Common.dll: 
(Location of symbol related to previous error)

Веб-сервер працює під керуванням Server 2003. Я перейшов до c: \ windows \ Assembly і фактично помітив, що перераховані 3 версії Common.dll. Найвища перерахована версія була 3.3.4269.17112

Я скопіював dll з версією: 3.3.4273.24368 у каталог складання. Потім я перекомпілював і повторно розгорнув свій код (напевно, надмірно, але о добре). Коли я відкрив веб-переглядач на новому сеансі і знову зайшов до URL-адреси сайту, я все одно отримав те саме повідомлення.

Я можу використовувати провідник Windows і перевірити, чи тепер перелічений Common.dll вищої версії також вказаний.

Що ще я можу розглянути для вирішення цього питання? Я не хочу змінювати посилання у своєму складі, щоб вказати на старішу версію.

3 ідеї, які ви можете спробувати:

1. Переконайтеся, що всі ваші dll складені на одній версії Common.
2. Перевірте, чи є у вас рішення посилання на рішення замість посилань на файли.
3. Використовуйте перенаправлення прив’язки у веб-конфіг. ( Спочатку пов'язана версія на машині зворотного зв'язку )

У мене була ця помилка, оскільки "Перебудувати" насправді не відбудовувались.

Рішення: Закрийте Visual Studio, дійсно перейдіть і видаліть папку бін, а потім перезавантажте, це може працювати краще.

Крім того, іноді Visual Studio брехні про посилання, тому перевіряйте HintPathсвої .csprojфайли.

Якщо ви використовуєте NuGet, варто перейти до "Управління пакетами NuGet для вирішення" , знайти пакунок, який викликає проблеми, і натисніть оновлення. Потім він повинен довести всі пакунки до останньої версії та вирішити проблему.

Варто зробити постріл, оскільки це швидко і легко.

Моя проблема полягала в тому, що у мене було 2 проекти, що посилаються на 2 різні копії одного і того ж DLL, які мали різні версії. Я виправив це, видаливши їх обох і переконавшись, що вони посилаються на той самий файл DLL.

Однією з можливих причин є те, що друга збірка встановлюється в GAC, тоді як перша збірка з більшим номером версії додається до Посилань проекту. Щоб перевірити це, двічі клацніть збірку у посиланнях на проект та перевірте, чи є ще одна збірка з таким самим іменем у браузері об’єктів.

Якщо це так, використовуйте утиліту gacutil.exe для видалення другої збірки з GAC. Наприклад, якщо це 64-бітні збірки:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name>

Перейдіть до посилання та додайте нову посилання на файл DLL, який викликає проблему, і переконайтеся, що всі ваші dll зібрані проти тієї ж версії. Це працює для мене, я сподіваюся, що він працює і для вас.

Моя команда щойно зіткнулася з цією проблемою в нашому побудові. Проблема була пов’язана з різницею елемента <HintPath> у файлі .csproj.

Наша спільна збірка мала правильний відносний шлях до каталогу, що містить наші еталонні збірки. Залежна збірка мала шлях від колишньої структури каталогів. Рішення успішно компілюється на розробниках, оскільки GAC вирішив посилання залежного на правильну версію, встановлену в C: \ Program Files. Навколишнє середовище складання застаріло встановити збірку (навіть якщо у неї не повинно було бути), що вона повернулася до цього, і, отже, помилка. Оновлення <HintPath> в текстовому редакторі виправило проблему.

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

Ви можете виправити це, оновивши пакунки нугів до загальної версії з усіма ПРОЕКТИМИ РЕШЕННЯ

Мав подібну проблему. Моя проблема полягала в тому, що в мене було декілька проектів в межах одного рішення, в якому кожен посилався на конкретну версію DLL, але різні версії. Рішенням було встановити "Specific Version" на false у всіх властивостях усіх посилань.

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

Я знайшов посилання та змінив PublicKeyToken з посилання на старіший.

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

У мене була така ж помилка. Я виправив помилку після установки Microsoft.AspNetCore.ALLв тестовий проект.

Папка колекції Handmade бібліотеки DLL
Якщо рішення є папка сміття для DLL-файлів з різних бібліотек
lib, source, libsі т.д.
Ви можете отримати ці неприємності , якщо ви будете відкривати своє рішення (на час) в єлей Visual Studio. І ваша папка для збирання dll якось пропущена або конкретний dll-файл пропущений.

Visual Studio намагається мовчки замінити посилання dll на щось самостійно. Якщо VS вдасться, нове посилання буде зберігатися для вашого локального рішення. Не для інших клонів / кас.

Тобто ваш <HintPath>ігнорується, і файл проекту (.csproj) не буде змінено.
Як приклад мені

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\lib\DocumentFormat.OpenXml.dll</HintPath>
</Reference>

На DocumentFormat.OpenXmlпосилання буде C:\Program Files (x86)\Open XML SDK\V2.5\libне з solution\..\libпапки.

швидкий обхід

• перевірити та відновити колекційну папку DLL
• з Solution Explorer виконайте Unload Project , а потім перезавантажте проект .

правильне рішення - перейти до менеджера пакунків NuGet.

для SharePoint переконайтесь, що під кореневою папкою у вас немає папки "bin" із DLL, якщо так, просто видаліть її. (і змінити "Копіювати локальне" на false на VS).

Посилання на проект веб-сайту зберігаються у його файлі web.config. Оновіть там посилання, щоб виправити помилку.

Я витратив деякий час на перегляд усіх посилань у своєму рішенні, перш ніж зрозумів, що забув про посилання у файлі web.config.

У мене була така ж проблема з UnitTestingProject, де в MainProject я використовував "System.Web.Mvc, версія = 3.0.0.0", а в UnitTestingProject я використовував "System.Web.Mvc, версія = 3.0.0.1"

Змініть наступне в <Reference Include="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <HintPath>..\packages\Microsoft.AspNet.Mvc.3.0.50813.1\lib\net40\System.Web.Mvc.dll</HintPath> </Reference>

Я отримав це після додавання Episerver Find на наш сайт та встановлення відповідного пакету NuGet для Episerver Find.

Виправлення було легко: оновіть також усі додатки, пов'язані з Episerver (навіть якщо вони здаються не пов'язаними: CMS, CMS.TinyMCE, CMS.UI тощо)

Після оновлення всіх можливих додатків Episerver та перекомпіляції помилка усунулася.

У моєму сценарії я змінив файл .csproj для свого додатка dotnetCore. Я помітив , що TargetFramework тег мав значення netcoreapp2.1 і RuntimeFrameworkVersion тег значення 2.0.0 . Тож я змінив RuntimeFrameworkVersion на 2.1.0 , зберег , перезапустив VS і відновив, а потім вирішив помилки.

Сподіваюся, це допоможе вам ...

Щасти,

Сугешан

У своєму проекті знайдіть посилання System.Web.Mvc перевірити версію.

Після цього клацніть правою кнопкою миші посилання -> збірки та пошукова система.web.mvc та налаштування його.

Проблему викликають різні версії цих збірок .

Редагувати: ніж вибирати керувати пакетами NuGet та встановлювати оновлення (якщо у вас є кілька проектів, встановіть і оновлення до них.)

Важливим оновленням є Microsoft.AspNet.Mvc та Microsoft.Net.Compilers цього не забувайте!

У нашій команді ми працювали на різних комп’ютерах з git. Хтось оновив, dllа у мене цього не було. Я щойно оновив свої посилання на залежності та вирішив проблему.

У мене була подібна проблема, я створив DLL, тобто A.dll, який посилався на інші DLL, тобто на B.dll.

Я створив додаток C.exe і посилався на DLL-файли A.dll та B.dll.

Рішення - видаливши посилання B.dll з c.exe, я зміг виправити проблему.

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