Ошибка 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 с более высокой версией теперь также отображается.

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

Ответы

Ответ 1

3 идеи для вас, чтобы попробовать:

  1. Убедитесь, что все ваши dll скомпилированы для одной и той же версии Common.
  2. Убедитесь, что в вашем решении есть ссылки на проекты вместо ссылок на файлы.
  3. Используйте перенаправления привязки в вашем файле web.config. (Первоначально связанная версия на wayback machine)

Ответ 2

У меня была эта ошибка, потому что "Rebuild" действительно не восстанавливался.

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

Кроме того, иногда Visual Studio лжет о ссылках, поэтому проверьте HintPath в ваших файлах .csproj.

Ответ 3

Если вы используете NuGet, стоит "Управление пакетами NuGet для решения" , находя пакет, который вызывает проблемы и ударяет обновление. Затем он должен довести все пакеты до последней версии и решить проблему.

Стоит сделать это быстро и просто.

Ответ 4

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

Ответ 5

Одна из возможных причин заключается в том, что вторая сборка установлена ​​в GAC, а первая сборка с более высоким номером версии добавляется к ссылкам проекта. Чтобы проверить это, дважды щелкните узел в ссылках на проект и проверьте, есть ли в обозревателе объектов другая сборка с тем же именем.

Если это так, используйте утилиту gacutil.exe для удаления второй сборки из GAC. Например, если это 64-разрядные сборки:

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

Ответ 6

Перейдите в ссылку и добавьте новую ссылку на свой DLL файл, который вызывает проблему, и убедитесь, что все ваши DLL файлы скомпилированы с той же версией. Это работает для меня, я надеюсь, что это сработает и для вас.

Ответ 7

Моя команда просто столкнулась с этой проблемой в нашей среде сборки. Проблема была связана с различием в <HintPath> элемент файла .csproj.

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

Ответ 8

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

Ответ 9

Была аналогичная проблема. Моя проблема заключалась в том, что у меня было несколько проектов в одном решении, каждое из которых ссылалось на определенную версию DLL, но на разные версии. Решение заключалось в том, чтобы установить "Специфическая версия" в значение false во всех свойствах всех ссылок.

Ответ 10

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

Я нашел ссылку и изменил значение PublicKeyToken с той, на которую ссылался старший.

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

Ответ 11

Коллекция коллекций 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 do Выгрузить проект, затем Обновить проект.

править

Ответ 12

для SharePoint, убедитесь, что в вашей корневой папке у вас нет папки "bin" с вашими DLL, если так просто удалите ее. (и измените "Скопировать местное" на false в VS).

Ответ 13

Ссылки в проекте веб-сайта хранятся в его файле web.config. Обновите ссылку там, чтобы исправить ошибку.

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

Ответ 14

У меня была такая же проблема с UnitTestingProject, где в MainProject я использовал "System.Web.Mvc, Version = 3.0.0.0", а в UnitTestingProject я использовал "System.Web.Mvc, Version = 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>

Ответ 15

В вашем проекте найдите ссылки System.Web.Mvc и проверьте версию.

После этого щелкните правой кнопкой мыши ссылки → сборки и найдите system.web.mvc и настройте его.

Проблема вызывает разные версии этих сборок.

Редактировать: чем управлять пакетами NuGet и устанавливать обновления (если у вас есть несколько проектов, установите обновления для них).

Важным обновлением является Microsoft.AspNet.Mvc, а Microsoft.Net.Compilers не забудьте об этом!

Ответ 16

В нашей команде мы работали на разных компьютерах с git. Кто-то обновил dll и у меня его не было. Я только что обновил ссылки на свои зависимости и проблема решена.

Ответ 17

У меня была аналогичная проблема, я создал DLL, то есть A.dll, которая ссылалась на другую DLL, то есть на B.dll.

Я создал приложение C.exe и ссылалось на DLL A.dll и B.dll.

Решение. При удалении ссылки на B.dll из c.exe я смог исправить проблему.

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