Попередження: Знайдено конфлікти між різними версіями однієї і тієї ж залежної збірки

Зараз я розробляю додаток .NET, який складається з 20 проектів. Деякі з цих проектів компілюються за допомогою .NET 3.5, інші - все ще є .NET 2.0 проектами (поки що проблем немає).

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

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

Що саме означає це попередження і чи можливо є можливість виключити це попередження (наприклад, використання #pragma disabled у файлах вихідного коду)?

Це попередження означає, що два проекти посилаються на одну збірку (наприклад 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 проект побудови виводу багатослівний, Детально) і після побудови пошукайте у вихідному вікні попередження та подивіться на текст трохи вище нього . (Порада капелюха до Паулоя, який запропонував це у коментарях до цієї відповіді) .

В основному це трапляється, коли для збірок, на які ви посилаєтеся, встановлено "Копіювати локальний" на "Істинно", це означає, що копія DLL розміщується у папці бін разом із вашим 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, якщо ви клацніть правою кнопкою миші на рішенні та керуйте пакунками цілих пакетів, є вкладка "Консолідація" , яка встановлює всі пакети на одну і ту ж версію.

Я щойно отримав це попереджувальне повідомлення, очистив рішення та перекомпілював (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 не в змозі визнати, що ваші проекти не синхронізовані. Пакети.config скажуть одне, але шлях, показаний у References - Properties, вказуватиме щось інше.

Якщо ви готові оновити свої залежності, зробіть наступне:

1. У Провіднику рішень клацніть правою кнопкою миші проект та натисніть «Керувати Nuget пакетами»

2. Виберіть вкладку "Встановлені пакети" на лівій панелі. Запишіть встановлені пакети. Якщо у вас є багато, спершу потрібно скопіювати свої пакети.config на робочий стіл, щоб перехрестити його в Google, щоб побачити, які встановлені Nuget pkgs

3. Видаліть ваші пакети. Добре, ми збираємось додати їх назад.

4. Негайно встановіть необхідні вам пакети. Що робитиме Nuget, це не лише отримати останню версію, але змінить ваші посилання, а також додасть перенаправлення обов'язкових для вас.

5. Зробіть це для всіх своїх проектів.

6. На рівні рішення зробіть Очищення та відновлення.

Можливо, ви захочете почати з нижчих проектів і пропрацювати свій шлях до проектів вищого рівня, а також відновлювати кожен проект у процесі роботи.

Якщо ви не хочете оновлювати свої залежності, ви можете використовувати консоль менеджера пакунків та використовувати синтаксис Update-Package -ProjectName [yourProjectName] [packageName] -Version [versionNumber]

Це насправді залежить від вашого зовнішнього компонента. Коли ви посилаєтесь на зовнішній компонент у додатку .NET, він генерує GUID для ідентифікації цього компонента. Ця помилка виникає, коли зовнішній компонент, на який посилається один із ваших проектів, має те саме ім'я та іншу версію, як інший такий компонент в іншій збірці.

Це іноді трапляється, коли ви використовуєте "Огляд", щоб знайти посилання та додати неправильну версію збірки, або у вас є інша версія компонента у вашому сховищі коду, як та, яка встановлена ​​на локальній машині.

Спробуйте знайти, у яких проектах є ці конфлікти, видаліть компоненти із довідкового списку, а потім додайте їх знову, переконуючись, що ви вказуєте на той самий файл.

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

=> насамперед видаліть цей примірник із програми видалення.

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

це вирішило мою проблему. Сподіваюся, що це теж допомагає вам. З повагою.

Також була ця проблема - у моєму випадку вона була викликана наявністю властивості "Specific Version" у ряді посилань, встановлених як true. Зміна цього значення на помилкове в цих посиланнях вирішило проблему.

Якщо я використовував NuGet, все, що я повинен був зробити:

1. клацніть правою кнопкою миші проект і натисніть Керувати пакетами NuGet ..

2. клацніть гвинтиком вгорі праворуч

3. натисніть вкладку Загальні в Менеджері пакунків NuGet над Джерелами пакунків

4. встановіть прапорець "Пропустити застосування прив'язувальних переадресацій" у Прив'язуванні переадресацій

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

Простенька

Я щойно витратив налагодження тієї ж проблеми. Зауважте, ця проблема може бути не між різними проектами, але насправді між декількома посиланнями в одному проекті, які залежать від різних версій одного dll / Assembly. У моєму випадку проблемою було 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 вище, і він працював на мене.

Інша річ, яку слід врахувати і перевірити - переконайтеся, що у вас немає жодної служби, яка використовує цю папку. якщо їх зупинити службу та відновити рішення

Здається, що в Mac Visual Studio є проблема під час редагування файлів .resx. Я не знаю, що сталося, але у мене виникла ця проблема, як тільки я редагував кілька файлів .resx на своєму Mac. Я відкрив проект у Windows, відкрив файли, і вони були так, ніби їх не редагували. Тож я редагував їх, зберігав, і все також знову почав працювати на Mac.

У мене виникла така проблема, коли мій проект посилався на NETStandardLibrary і одна з посилань на збірки була опублікована для netcore. Просто опублікував це як нестандартний стандарт і проблеми не було

Ось рішення, стиль .NET Core 3.0: https://github.com/HTD/ref-check

Коли ви знайдете які конфлікти, можливо, вам вдасться вирішити конфлікти. Якщо суперечливі посилання є з інших пакетів, вам або не пощастило, або вам потрібно використовувати джерела замість цього.

У моєму випадку часто конфліктуючі пакети є моїми власними силами, тому я можу виправити проблеми залежності та повторно їх опублікувати.