it-swarm.com.ru

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

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

Обнаружены конфликты между разными версиями одной и той же зависимой сборки, которые не удалось разрешить. Эти конфликты ссылок перечислены в журнале сборки, когда подробность журнала установлена ​​на подробный. C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets

Когда я дважды щелкаю это сообщение, оно открывает файл C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets , но я ничего не понимаю в нем.

Я использую Visual Studio Express 2013 для Интернета.

Как мне выяснить, что не так и с каким DLL и как я могу затем отключить предупреждение?

298
Water Cooler v2

В то время как другие ответы говорят это, они не делают это явным, поэтому я буду ....

На VS2013.2, чтобы фактически запустить передачу цитируемой информации, вам не нужно читать сообщение, которое говорит:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets (1697,5): предупреждение MSB3277: обнаружены конфликты между различными версиями одной и той же зависимой сборки, которые не могут быть разрешены. Эти конфликты ссылок перечислены в журнале сборки, когда подробность журнала установлена ​​на подробное значение.

Это неверно (или, по крайней мере, так было в некоторых версиях Visual Studio - похоже, все в порядке в обновленном VS2015 Update 3 или более поздней версии). Вместо этого установите его в Diagnostic (из Инструменты-> Параметры-> Проект и решения-> Построить и запустить, установите Детализация вывода проекта сборки MSBuild), после чего вы будете увидеть сообщения, такие как:

Возник конфликт между «Newtonsoft.Json, версия = 6.0.0.0, культура = нейтральная, PublicKeyToken = 30ad4fe6b2a6aeed» и «Newtonsoft.Json, версия = 6.0.5.17707, культура = нейтральная, PublicKeyToken = 30ad4fe6b2a6aeed».

  • «Newtonsoft.Json, Версия = 6.0.0.0, Культура = нейтральный, PublicKeyToken = 30ad4fe6b2a6aeed» был выбран, поскольку он был основным, а «Newtonsoft.Json, Версия = 6.0.5.17707, Культура = нейтральный, PublicKeyToken = 30ad4fe6b2a6aeed» не был.

Затем

  • Ctrl-Alt-O чтобы перейти к окну Build output
  • ищите "было выбрано", чтобы найти детализацию. 

... И да, для тех, кто рассматривает детали сообщения [диагностики], для этого невежды было новостью, что в городе существует соглашение, согласно которому все версии 6.x являются внутренней версией сборки 6.0.0.0, то есть только основным компонентом SemVer переходит в сборочную версию :)

422
Ruben Bartelink

Запустите msbuild Foo.sln /t:Rebuild /v:diag (из C:\Program Files (x86)\MSBuild\12.0\bin), чтобы построить свое решение из командной строки и получить более подробную информацию, затем найдите .csproj., который регистрирует предупреждение и проверяет его ссылки и ссылки на другие проекты, использующие ту же общую сборку, которая отличается по версии.

Правка: Вы также можете установить подробность сборки непосредственно в VS2013. Перейдите в меню Tools> Options, затем перейдите к Projects and Solutions и установите для MSBuild Diagnostic.

Правка: Несколько разъяснений, как я только что получил один сам. В моем случае предупреждение было связано с тем, что я добавил ссылку, используя Resharper Prompt, в отличие от диалогового окна «Добавить ссылку», которое делало его без версии, даже если доступны как версии 4, так и версии 12.

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework" />

против

<Reference Include="Microsoft.Build, Version=12.0.0.0, ..." />
<Reference Include="Microsoft.Build.Framework, Version=12.0.0.0, ..." />

В журнале MSBuild с многословием /v:diag это выглядело следующим образом. с указанием деталей, которые противоречили двум ссылкам:

  There was a conflict between 
  "Microsoft.Build.Framework, Version=4.0.0.0, ..." and 
  "Microsoft.Build.Framework, Version=12.0.0.0, ...". (TaskId:16)

      "Microsoft.Build.Framework, Version=4.0.0.0, ..." was chosen because it was primary and 
      "Microsoft.Build.Framework, Version=12.0.0.0, ..." was not. (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=4.0.0.0, ..." 
      [C:\...\v4.5.1\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v4.5.1\Microsoft.Build.Framework.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v4.5.1\Microsoft.Build.Framework.dll". (TaskId:16)
              Microsoft.Build.Framework (TaskId:16)

      References which depend on "Microsoft.Build.Framework, Version=12.0.0.0, ..." 
      [C:\...\v12.0\Microsoft.Build.Framework.dll]. (TaskId:16)

          C:\...\v12.0\Microsoft.Build.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

          C:\...\v12.0\Microsoft.Build.Engine.dll (TaskId:16)
            Project file item includes which caused reference "C:\...\v12.0\Microsoft.Build.Engine.dll". (TaskId:16)
              Microsoft.Build, Version=12.0.0.0, ... (TaskId:16)

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3277: 
Found conflicts between different versions of the same dependent Assembly that could not be resolved.  
These reference conflicts are listed in the build log when log verbosity is set to detailed. 
[C:\Users\Ilya.Kozhevnikov\Dropbox\BuildTree\BuildTree\BuildTree.csproj]
69
Ilya Kozhevnikov

Я могу только поддержать дальнейший ответ Рубена сравнением двух отображаемых сообщений:

enter image description here

и сообщение:

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets (1697,5): предупреждение MSB3277: обнаружены конфликты между различными версиями одной и той же зависимой сборки, которые не могут быть разрешены. Эти конфликты ссылок перечислены в журнале сборки, когда для подробности журнала задано подробное описание.

Итак, Рубен прав - это просто неправда. Там нет никаких конфликтов, просто отсутствует Ассамблея. Это особенно скучно, когда проект является приложением ASP.NET, поскольку представления компилируются по требованию, то есть непосредственно перед первым отображением. Это когда становится необходимым иметь Ассамблею доступной. (Существует возможность предварительно скомпилировать представления вместе с остальной частью кода, но это другая история .) С другой стороны, если вы установите многословие Diagnostic, вы получите следующий вывод :

C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets (1697,5): предупреждение MSB3245: не удалось разрешить эту ссылку. Не удалось найти сборку "System.Web.Razor, версия = 3.0.0.0, культура = нейтральная, PublicKeyToken = 31bf3856ad364e35, processorArchitecture = MSIL". Убедитесь, что сборка существует на диске. Если эта ссылка требуется вашим кодом, вы можете получить ошибки компиляции.

В результате все, что вам нужно сделать, это либо:

  1. Добавьте ссылку на сборку вручную (найдите ее на диске, может быть GAC, и добавьте ее как «прямую» ссылку), или 
  2. Используйте пакет NuGet (если он опубликован в галерее), чтобы загрузить его и сослаться на содержащуюся в нем сборку.

Подробнее о галерее NuGet здесь . Подробнее о предварительной компиляции представлений ASP.NET здесь .

34
Alexander Christov

Повторяя один из комментариев от @elshev Щелкните правой кнопкой мыши решение -> Управление пакетами NuGet для решения -> В разделе Консолидация вы можете увидеть, были ли установлены разные версии одного и того же пакета. Обновите пакеты там. Ошибка конфликта разрешена.

15
Shaswat Rungta

Изменение детализации сборки в визуальной студии поможет указать правильное направление. Выполните следующие шаги, чтобы изменить многословие в VS

  1. Зайдите в Сервис-> Параметры меню в VS
  2. Открытые проекты и решения-> Построить и запустить
  3. Измените значение многословности выходных данных сборки проекта MSBuild. Выберите одно из Quiet, Minimal, Normal, Detailed и Diagnostic

Проверьте окно вывода (Ctrl+Alt+O) в VS, чтобы увидеть изменения в журнале сборки.

15
sree

и как я тогда уберу предупреждение?

Возможно, вам придется переустановить или обновить пакеты NuGet, чтобы это исправить.

14
CrazyPyro

Как указано в проблема 6583 CLI dotnet проблему следует решить с помощью команды dotnet nuget locals --clear all.

6
Jose L. Garcia

Я использую Visual Studio 2017 и столкнулся с этим при обновлении некоторых пакетов Nuget. Что мне помогло, так это открыть мой файл web.config, найти узел <runtime><assemblyBinding> и удалить его. Сохраните web.config и пересоберите проект.

Посмотрите на окно Error List. Вы увидите, что выглядит как массивно длинное предупреждение о связывающих конфликтах. Дважды щелкните по нему, и он автоматически воссоздает блок <runtime><assemblyBinding> с правильными сопоставлениями. 

5
RandomHandle

Я мог решить эту проблему, установив Newtonsoft Json в веб-проекте с пакетами Nuget

3
Carolina

Очевидно, есть много разных причин и, следовательно, множество решений этой проблемы. Чтобы добавить меня в микс, мы обновили сборку (System.Net.Http), на которую ранее непосредственно ссылались в нашем веб-проекте, до версии, управляемой NuGet. Это удалило прямую ссылку в этом проекте, но наш тестовый проект все еще содержал прямую ссылку. Обновление обоих проектов для использования сборки под управлением NuGet решило проблему.

3
joelmdev

Если вы внесли какие-либо изменения в пакеты - снова откройте sln. Это сработало для меня!

2
Naumaan Shaikh

Я обнаружил, что иногда устанавливаются пакеты nuget (что, я предполагаю). В ядре .NET требуются компоненты или другие элементы, которые конфликтуют с уже установленной платформой. Мое решение было открыть файл проекта (.csproj) и удалить эти ссылки. Например, System.IO, System.Threading и другие, как правило, добавляются, когда Microsoft.Bcl включен через какой-то недавно установленный пакет NuGet. Там нет причин для конкретных версий тех, в моих проектах, поэтому я удаляю ссылки и сборки проекта. Надеюсь, это поможет.

Вы можете найти в вашем проекте файл «reference» и удалить конфликты. Если они включены в System, избавьтесь от них, и сборка должна работать. Это может не ответить на все случаи этой проблемы - я проверяю, знаете ли вы, что сработало для меня :)

Пример того, что я прокомментировал:

<!-- <Reference Include="System.Runtime, Version=2.6.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"> -->
  <!-- <HintPath>$(SolutionDir)packages\Microsoft.Bcl.1.1.9\lib\net40\System.Runtime.dll</HintPath> -->
  <!-- <Private>True</Private> -->
<!-- </Reference> -->

1
Auri Rahimzadeh

Я удалил Microsoft ASP.NET MVC nuget.org из пакета управления NuGet и снова переустановил его. При переустановке он разрешил все конфликты, связанные с версией бритвы. Попытайся .

0
jitendra r

Я только столкнулся с этим и проблемой после переключения пакета от nuget до локально ссылающихся dll. Проблема заключалась в старом связывании во время выполнения в app.config.

0
Tom Makin

Я последовал совету нескольких ответов здесь, чтобы выяснить, что не так, но ни один из ответов, казалось, не объяснял, как это исправить. Моя проблема заключалась в том, что одна ссылка требовала другой версии второй ссылки. Итак, Newtonsoft была в версии 6, но некоторые другие DLL хотели 4.5. Затем я обновил Newtonsoft, как и один из предложенных ответов, и это ухудшило ситуацию.

Таким образом, я на самом деле понизил мою установку Newtonsoft и предупреждение исчезло (VS 2017):

Щелкните правой кнопкой мыши Ссылки в обозревателе решений и выберите Управление пакетами NuGet ... На вкладке "Установлено" найдите Newtonsoft (или какой-либо другой конфликт). С правой стороны рядом с "Версией" отображается раскрывающийся список, который можно изменить на более старую. версии. Для меня не было очевидно, что этот выпадающий список может быть использован для понижения.

0
Andrew

Я изменил многословность MSBuild на Diagnostic.but не мог найти, где проблема, поэтому согласно ответам выше у меня был этот код в app.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
<sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="XbimXplorer.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false" />
</sectionGroup>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>

Поэтому я просто изменил первую Систему, Версия с 4.0.0.0 на 12.0.0.0, и мой проект сработал.

0
Pantelitsa Mavrovounioti

Как и в других ответах, установите уровень ведения журнала вывода на подробный и найдите там конфликты, которые подскажут вам, где искать дальше.

В моем случае, он отправил меня в нескольких направлениях в поисках источника ссылок, но в итоге оказалось, что проблема была в одном из моих проектов переносимых библиотек классов, он был нацелен на неправильную версию и тянул свою собственную версия ссылок в, следовательно, конфликты. Быстрая переориентация и проблема была решена.

0
car1bo

Запустите команду Update-Package через консоль диспетчера пакетов

Это исправит MSB3277, то, что он делает, переустанавливает все пакеты и все связанные сборки, с которыми они поставляются, до максимально возможной версии. Также возможно обновить только конкретный пакет. Или, если хотите, понизьте версию после обновления, эта проблема исправилась для меня несколько раз. В зависимости от количества пакетов Nuget этот процесс может занять несколько минут.

Больше информации на официальных документах https://docs.Microsoft.com/en-us/nuget/consume-packages/reinstall-and-updating-packages

0
Aistis Taraskevicius

У меня было это предупреждение после перехода на ссылку на пакет. В диагностическом выводе была информация о том, что на библиотеку ссылалась та же библиотека. Это может быть ошибка новой ссылки на пакет. Решение состояло в том, чтобы включить AutoGenerateBindingRedirects и удалить пользовательское перенаправление привязки.

0
raV720