Ошибка CS1705: «версия более поздней, чем указанная сборка»

110

Я немного изучал это, и пока не решил. Я получаю следующее сообщение об ошибке:

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 с более высокой версией.

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

jbizzle
источник
2
Сумасшедшие *.*номера версий. Восстановите все, только так можно быть уверенным.
Ханс Пассан,

Ответы:

39

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

  1. Убедитесь, что все ваши DLL скомпилированы для одной и той же версии Common.
  2. Убедитесь, что в вашем решении есть ссылки на проекты, а не на файлы.
  3. Используйте перенаправление привязки в своем web.config. ( Первоначально связанная версия на Wayback Machine )
Якуб Конецки
источник
Все еще доступно на wayback machine и microsoft
nitzel 09
68

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

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

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

Николя Рауль
источник
2
Этот спас мой бекон. Запускать локально было нормально, но я опубликовал изменение, и все пошло не так. Удаление содержимого онлайн-папки bin заставило все снова синхронизироваться. Спасибо!
pStan
41

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

Стоит попробовать, так как это быстро и легко.

CountZero
источник
2
Это решило проблему для меня, спасибо. Моя ситуация была немного другой: он не был указан в обновлениях, поэтому мне пришлось перейти к установке, и было окно, в котором отображалась версия пакета для каждого проекта. Я обновлял некоторые старые модули до новой версии cms, поэтому мне пришлось перейти к проблемным пакетам, выбрать их и нажать установить. Возможно, это произошло из-за того, что cms только что перешла на использование nuget, но вы избавили меня от утомительного csprojредактирования!
rtpHarry
3
Обязательно обновляйте пакеты NuGet на уровне решения, а не на уровне проекта.
Джесс
2
Это, безусловно, должен быть принятым ответом, я не читал это, но случайно попробовал свое решение, которое сработало как шарм.
baymax
30

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

Эндрю Нго
источник
13

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

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

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name>
jgong
источник
Два года спустя ваше предложение сработало как шарм. Просмотр ссылок в обозревателе объектов сортировал его.
ceebreenk
3

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

Рахул
источник
2

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

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

Рассел Спейт
источник
2

Проблема возникает, если пакеты nuget различаются в нескольких проектах в рамках решения.

Вы можете исправить это, обновив пакеты nuget до общей версии со всеми ПРОЕКТАМИ в РЕШЕНИИ.

Кришна Прасад S
источник
1

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

гнучу
источник
1

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

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

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

Гарри
источник
1

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

Хактан Энес Бичер
источник
0

Папка коллекции 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
  • из обозревателя решений выполните выгрузку проекта , затем перезагрузите проект .

right Обходной путь - перейти на диспетчер пакетов NuGet.

it3xl
источник
0

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

Bresleveloper
источник
0

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

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


источник
0

У меня была такая же проблема с 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>

Буминда
источник
0

Я получил это после добавления Episerver Find на наш сайт и установки соответствующего пакета NuGet для Episerver Find.

Исправить это было просто: обновите все надстройки, связанные с Episerver (даже если они кажутся не связанными: CMS, CMS.TinyMCE, CMS.UI и т. Д.)

После обновления всех возможных надстроек Episerver и перекомпиляции ошибка исчезла.

webDevAndEverythingElse
источник
0

В моем сценарии я редактировал файл .csproj для своего приложения dotnetCore. Я заметил, что тег TargetFramework имеет значение netcoreapp2.1, а тег RuntimeFrameworkVersion - значение 2.0.0 . Поэтому я изменил RuntimeFrameworkVersion на 2.1.0 , сохранил, перезапустил VS и перестроил, а затем ошибки.

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

Удачи,

Сугешан

Сугешан Говинддами
источник
-1

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

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

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

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

Важное обновление - Microsoft.AspNet.Mvc и Microsoft.Net.Compilers , не забывайте об этом!

Hadnazzar
источник
-1

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

Масуд Дарвишян
источник
-3

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

Я создал приложение C.exe и сослался на библиотеки DLL A.dll и B.dll.

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

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

Яхья
источник