Предупреждение. Обнаружены конфликты между разными версиями одной и той же зависимой сборки.

В настоящее время я занимаюсь разработкой приложения .NET, которое состоит из 20 проектов. Некоторые из этих проектов скомпилированы с использованием .NET 3.5, некоторые все еще являются проектами .NET 2.0 (пока проблем нет).

Проблема в том, что если я включаю внешний компонент, я всегда получаю следующее предупреждение:

"Found conflicts between different versions of the same dependent assembly".

Что именно означает это предупреждение и есть ли возможность исключить это предупреждение (например, с помощью отключения #pragma в файлах исходного кода)?

Это предупреждение означает, что два проекта ссылаются на одну и ту же сборку (например System.Windows.Forms), но для двух проектов требуются разные версии. У вас есть несколько вариантов:

1. Перекомпилируйте все проекты, чтобы использовать одинаковые версии (например, переместите все в .Net 3.5). Это предпочтительный вариант, потому что весь код выполняется с версиями зависимостей, с которыми они были скомпилированы.

2. Добавьте редирект привязки . Это подавит предупреждение. Однако ваши проекты .Net 2.0 будут (во время выполнения) связаны с версиями .Net 3.5 зависимых сборок, таких как System.Windows.Forms. Вы можете быстро добавить перенаправление привязки, дважды щелкнув по ошибке в Visual Studio.

3. Использование CopyLocal=true. Я не уверен, если это подавит предупреждение. Это, как и вариант 2 выше, будет означать, что все проекты будут использовать .Net 3.5 версию System.Windows.Forms.

Вот несколько способов определить оскорбительные ссылки:

• Вы можете использовать утилиту, такую ​​как найденная на https://gist.github.com/1553265
• Еще один простой метод - установить подробность вывода «Построить» («Инструменты», «Опции», «Проекты и решения», «Построить и запустить», «Детализация вывода при сборке проекта MSBuild», «Подробно») и после сборки найдите в окне вывода предупреждение и посмотрите на текст чуть выше него. , (Шляпа подсказка для pauloya, кто предложил это в комментариях к этому ответу) .

В основном это происходит, когда для сборок, на которые вы ссылаетесь, для параметра «Копировать локальный» установлено значение «Истина», что означает, что копия библиотеки DLL помещается в папку bin вместе с вашим exe-файлом.

Так как Visual Studio также будет копировать все зависимости ссылочной сборки, в конечном итоге можно получить две разные сборки одной и той же сборки, на которые ссылаются. Это более вероятно, если ваши проекты находятся в отдельных решениях, и поэтому могут быть скомпилированы отдельно.

Я обошел это, установив Copy Local в False для ссылок в сборочных проектах. Делайте это только для исполняемых файлов / веб-приложений, где вам нужна сборка для запуска готового продукта.

Надеюсь, что это имеет смысл!

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

Самый простой способ выяснить, что такое «оскорбительная ссылка (и)», - установить подробность вывода «Сборка» («Инструменты», «Параметры», «Проекты и решения», «Построить и запустить», «Детализация вывода сборки проекта MSBuild», «Подробно») и после сборки выполнить поиск в окне вывода. для предупреждения. Посмотрите текст прямо над ним.

Например, когда вы ищете на панели вывода «конфликт», вы можете найти что-то вроде этого:

3>  There was a conflict between "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
3>      "EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was not.

Как вы можете видеть, существует конфликт между версиями EF 5 и 6.

У меня была такая же проблема с одним из моих проектов, однако ни один из вышеперечисленных не помог устранить предупреждение. Я проверил подробный файл журнала сборки, я использовал AsmSpy, чтобы убедиться, что я использовал правильные версии для каждого проекта в затронутом решении, я дважды проверил фактические записи в каждом файле проекта - ничего не помогло.

В конце концов оказалось, что проблема заключалась во вложенной зависимости одной из ссылок, которые у меня были в одном проекте. Эта ссылка (A), в свою очередь, требовала другой версии (B), на которую ссылались непосредственно все другие проекты в моем решении. Обновление ссылки в ссылочном проекте решило это.

Solution A
+--Project A
   +--Reference A (version 1.1.0.0)
   +--Reference B
+--Project B
   +--Reference A (version 1.1.0.0)
   +--Reference B
   +--Reference C
+--Project C
   +--Reference X (this indirectly references Reference A, but with e.g. version 1.1.1.0)

Solution B
+--Project A
   +--Reference A (version 1.1.1.0)

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

В Visual Studio, если вы щелкнете правой кнопкой мыши по решению и управляете пакетами nuget, появится вкладка «Консолидация», в которой для всех пакетов установлена ​​одинаковая версия.

Я только что получил это предупреждающее сообщение и очистил решение и перекомпилировал (Build -> Clean Solution), и оно ушло.

У меня была та же проблема, и я решил, изменив следующее в web.config.

Это случилось со мной, потому что я запускаю приложение, используя Newtonsoft.Json 4.0

Из:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

Для того, чтобы:

<dependentAssembly>
  <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-6.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

У меня есть другой способ сделать это, если вы используете Nuget для управления своими зависимостями. Я обнаружил, что иногда VS и Nuget не совпадают, и Nuget не может распознать, что ваши проекты не синхронизированы. Packages.config скажет одно, а путь, указанный в разделе «Ссылки», в свойствах будет указано другое.

Если вы хотите обновить свои зависимости, сделайте следующее:

1. В обозревателе решений щелкните правой кнопкой мыши проект и выберите «Управление пакетами Nuget».

2. Выберите вкладку «Установленные пакеты» в левой панели. Запишите установленные пакеты. Если у вас много, вы можете сначала скопировать ваш пакет

3. Удалите ваши пакеты. Хорошо, мы собираемся добавить их обратно.

4. Немедленно установите нужные вам пакеты. Что Nuget сделает, так это не только предоставит вам последнюю версию, но и изменит ваши ссылки, а также добавит для вас перенаправления привязки.

5. Сделайте это для всех ваших проектов.

6. На уровне решения выполните Очистку и Перестройку.

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

Если вы не хотите обновлять свои зависимости, вы можете использовать консоль диспетчера пакетов и использовать синтаксис Update-Package -ProjectName [yourProjectName] [packageName] -Version [versionNumber]

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

Это иногда происходит, когда вы используете «Обзор», чтобы найти ссылки и добавить неправильную версию сборки, или у вас есть другая версия компонента в вашем хранилище кода, чем та, которую вы установили на локальном компьютере.

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

=> проверьте, что какой-то экземпляр приложения будет установлен частично.

=> Прежде всего удалите этот экземпляр из приложения удаления.

=> затем очистите, перестройте и попробуйте развернуть.

это решило мою проблему. надеюсь, это поможет вам тоже. Наилучшие пожелания.

Также имелась эта проблема - в моем случае это было вызвано тем, что свойство «Конкретная версия» для ряда ссылок было установлено в true. Изменение этого значения на false для этих ссылок решило проблему.

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

1. щелкните правой кнопкой мыши проект и выберите Управление пакетами NuGet.

2. нажмите на винтик в правом верхнем углу

3. перейдите на вкладку Общие в диспетчере пакетов NuGet над источниками пакетов

4. установите флажок «Пропустить применение перенаправлений привязки» в разделе «Переадресация привязок».

5. Очистить и восстановить, и предупреждение ушло

Очень просто

Я просто потратил некоторое время на отладку той же проблемы. Обратите внимание, что эта проблема может возникать не между разными проектами, а на самом деле между несколькими ссылками в одном проекте, которые зависят от разных версий одной и той же dll / сборки. В моем случае проблема заключалась в FastMember.dllнесовпадении эталонных версий, которое происходит от двух разных пакетов NuGet в одном проекте. Когда мне дали проект, он не скомпилировался, потому что пакеты NuGet отсутствовали, а VS отказался восстанавливать отсутствующие пакеты. Через меню NuGet я вручную обновляю все NuGets до последней версии, то есть когда появилось предупреждение.

В Visual Studio Tools > Options > Build and Run > MSBuld Project build output verbosity: (set to) Diagnostics.найдите строки There was a conflict betweenв Outputокне. Ниже приведена часть вывода, которую я получил:

1>  There was a conflict between "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null". (TaskId:19)
1>      "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" was chosen because it was primary and "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" was not. (TaskId:19)
1>      References which depend on "FastMember, Version=1.5.0.0, Culture=neutral, PublicKeyToken=null" [C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll]. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\FastMember.1.5.0\lib\net461\FastMember.dll". (TaskId:19)
1>              FastMember, Version=1.5.0.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)
1>      References which depend on "FastMember, Version=1.3.0.0, Culture=neutral, PublicKeyToken=null" []. (TaskId:19)
1>          C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll (TaskId:19)
1>            Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll". (TaskId:19)
1>              ClosedXML, Version=0.94.2.0, Culture=neutral, processorArchitecture=MSIL (TaskId:19)

Заметь Project file item includes which caused reference "C:\Users\ksd3jvp\Source\Temp\AITool\Misra\AMSAITool\packages\ClosedXML.0.94.2\lib\net46\ClosedXML.dll"

ClosedXML.dllисходит от ClosedXMLNuGet и зависит от FastMember.dll 1.3.0.0. Кроме того, FastMemberв проекте есть также Nuget, и он есть FastMember.dll 1.5.0.0. Несоответствие !

Я удалил ClosedXML& FastMemberNuGets, потому что я имел перенаправление привязки и установил только последнюю версию, ClosedXMLкоторая исправила проблему!

Это случилось со мной тоже. На одну dll ссылались дважды: один раз напрямую (в ссылках) и один раз косвенно (ссылались на другой ссылочный проект). Я удалил прямую ссылку, почистил и восстановил решение. Проблема исправлена.

1. Откройте «Обозреватель решений».
2. Нажмите «Показать все файлы»
3. Развернуть «Рекомендации»
4. Вы увидите одну (или более) ссылку (-и) со значком, немного отличающимся от остальных. Как правило, это с желтой рамкой, предлагающей вам принять к сведению. Просто удали это.
5. Добавьте ссылку назад и скомпилируйте свой код.
6. Вот и все.

В моем случае была проблема со ссылкой на MySQL. Так или иначе, я мог бы перечислить три его версии под списком всех доступных ссылок; для .net 2.0, .net 4.0 и .net 4.5. Я следовал процессу с 1 по 6 выше, и он работал для меня.

Еще одна вещь, которую следует рассмотреть и проверить, - убедиться, что у вас нет запущенной службы, использующей эту папку bin. если их остановить сервис и восстановить решение

Кажется, есть проблема в Mac Visual Studio при редактировании файлов .resx. Я действительно не знаю, что случилось, но у меня возникла эта проблема, как только я отредактировал некоторые файлы .resx на моем Mac. Я открыл проект в Windows, открыл файлы, и они были, как будто они не были отредактированы. Поэтому я отредактировал их, сохранил, и все снова начало работать на Mac.

У меня была такая проблема, когда в моем проекте была ссылка на NETStandardLibrary, и одна из сборок, на которые есть ссылки, была опубликована для netcore. Просто опубликовал его как netstandard и проблема исчезла

Вот решение в стиле .NET Core 3.0: https://github.com/HTD/ref-check

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

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