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

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

Нашел конфликты между разными версиями одной и той же зависимой сборки, которые невозможно было решить. Эти ссылочные конфликты перечислены в журнале построения, когда подробные сведения о журналах заданы. 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 и как я могу сделать предупреждение?

Ответ 1

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

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

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

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

Был конфликт между "Newtonsoft.Json, Version = 6.0.0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" и "Newtonsoft.Json, Version = 6.0.5.17707, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed".

"Newtonsoft.Json, Version = 6.0.0.0, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" был выбран потому, что он был первичным и "Newtonsoft.Json, Version = 6.0.5.17707, Culture = neutral, PublicKeyToken = 30ad4fe6b2a6aeed" не был.

Тогда

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

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

Ответ 2

Запустите 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, а не диалоговое окно Add Reference, которое делало это бездействующим, даже если оба варианта v4 и v12 доступны для выбора.

<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 verbosity это выглядело следующим образом. давая детали, с которыми столкнулись две ссылки: -

  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]

Ответ 3

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

и сообщение:

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

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

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

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

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

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

Ответ 4

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

Ответ 5

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

Перейдите на Tools-> меню опций в VS
Открытые проекты и Solutions-> Построить и запустить
Измените значение многословности выходных данных сборки проекта MSBuild. Выберите один из Quiet, Minimal, Normal, Detailed и Diagnostic

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

Ответ 6

и как я могу сделать предупреждение?

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

Я мог бы решить эту установку Newtonsoft Json в веб-проекте с помощью самодельных пакетов

Ответ 10

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

Ответ 11

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

Ответ 12

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

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

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

<!-- <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> -->

Ответ 13

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

Ответ 14

Я изменил многословие 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, и мой проект работал.

Ответ 15

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

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

Ответ 16

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

Ответ 17

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

Ответ 18

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

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

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

Ответ 19

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

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

Дополнительная информация о официальных документах https://docs.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages