Znaleziono konflikty między różnymi wersjami tego samego zależnego zestawu, których nie można rozwiązać

Po wyczyszczeniu, a następnie skompilowaniu mojego rozwiązania zawierającego kilka projektów, okno wyjściowe informuje, że kompilacja się powiodła. Jednak gdy przeglądam okno listy błędów , pokazuje mi to ostrzeżenie:

Znaleziono konflikty między różnymi wersjami tego samego zależnego zestawu, których nie można rozwiązać. Te konflikty referencyjne są wymienione w dzienniku kompilacji, gdy szczegółowość dziennika jest ustawiona na szczegółową. C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets

Po dwukrotnym kliknięciu tego komunikatu otwiera się plik C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets , ale nic w nim nie rozumiem.

Korzystam z programu Visual Studio Express 2013 dla Internetu.

Jak dowiedzieć się, co jest nie tak i z jaką biblioteką DLL, a następnie jak usunąć ostrzeżenie?

eta: Istnieje artykuł zabójcy na ten temat autorstwa własnego @Nick Cravera SO, który powinieneś przeczytać

Podczas gdy inne odpowiedzi to mówią, nie wyrażają tego wprost, więc ja ...

W VS2013.2, aby faktycznie wyzwolić emisję cytowanych informacji, nie musisz czytać wiadomości, która mówi:

C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): ostrzeżenie MSB3277: Znaleziono konflikty między różnymi wersjami tego samego zestawu zależnego, których nie można rozwiązać. Te konflikty referencyjne są wymienione w dzienniku kompilacji, gdy szczegółowość dziennika jest ustawiona na szczegółową .

Jest to niepoprawne (a przynajmniej tak było w przypadku niektórych wersji Visual Studio - wydaje się być poprawne w aktualnej wersji VS2015 Update 3 lub nowszej). Zamiast tego zmień go na Diagnostyczny (z Narzędzia-> Opcje-> Projekt i rozwiązania-> Kompiluj i uruchom , ustaw gadatliwość wyjściową kompilacji projektu MSBuild ), po czym zobaczysz komunikaty takie jak:

Wystąpił konflikt między „Newtonsoft.Json, wersja = 6.0.0.0, Kultura = neutralny, PublicKeyToken = 30ad4fe6b2a6aeed” i „Newtonsoft.Json, wersja = 6.0.5.17707, Kultura = neutralny, PublicKeyToken = 30ad4fe6b2a6aeed”.

• Wybrano „Newtonsoft.Json, wersja = 6.0.0.0, Kultura = neutralny, PublicKeyToken = 30ad4fe6b2a6aeed”, ponieważ był on pierwotny, a „Newtonsoft.Json, wersja = 6.0.5.17707, Kultura = neutralny, PublicKeyToken = 30ad4fe6b2a6aeed” nie.

Następnie

• Ctrl-Alt-O przejść do okna Buduj wyjście
• wyszukaj „ został wybrany ”, aby znaleźć drążenie.

... I tak, dla tych, którzy patrzą na szczegóły komunikatu [diagnostycznego], to było dla tego ignoranta wiadomości, że w mieście istnieje konwencja, w której wszystkie 6.xwersje są wewnętrznie Wersja Montażowa 6.0.0.0, tj. Tylko składnik SemVer Major wchodzi do Zgromadzenia Wersja :)

Uruchom msbuild Foo.sln /t:Rebuild /v:diag(z C:\Program Files (x86)\MSBuild\12.0\bin), aby zbudować rozwiązanie z wiersza polecenia i uzyskać trochę więcej szczegółów, a następnie znajdź to, .csproj.które rejestruje ostrzeżenie i sprawdź jego odniesienia i odniesienia do innych projektów, które używają tego samego wspólnego zestawu, który różni się wersją.

Edycja: Możesz także ustawić szczegółowość kompilacji bezpośrednio w VS2013. Przejdź do Tools> Optionsmenu, a następnie przejdź do Projects and Solutionsi ustaw opcję Szczegółowość MSBuild na Diagnostic.

Edycja: Kilka wyjaśnień, ponieważ sam je dostałem. W moim przypadku ostrzeżenie było spowodowane tym, że dodałem referencję za pomocą monitu Resharper, w przeciwieństwie do okna dialogowego Dodaj referencję, co sprawiło, że nie było wersji, mimo że można wybrać zarówno wersję v4, jak i wersję 12.

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

vs

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

W /v:diagszczegółowym dzienniku MSBuild wyglądało to następująco. podając szczegóły, z którymi dwa odniesienia były sprzeczne:

  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]

Mogę tylko wesprzeć dalszą odpowiedź Rubena w porównaniu dwóch wyświetlanych komunikatów:

i wiadomość:

C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): ostrzeżenie MSB3277: Znaleziono konflikty między różnymi wersjami tego samego zestawu zależnego, których nie można rozwiązać. Te konflikty referencyjne są wymienione w dzienniku kompilacji, gdy szczegółowość dziennika jest ustawiona na szczegółową .

Ruben ma rację - to po prostu nieprawda. Brak konfliktów, tylko brakujący zestaw. Jest to szczególnie nudne, gdy projekt jest aplikacją ASP.NET, ponieważ widoki są kompilowane na żądanie , to znaczy tuż przed pierwszym wyświetleniem. Wtedy konieczne staje się udostępnienie zestawu. (Istnieje możliwość wstępnej kompilacji widoków wraz z resztą kodu, ale to już inna historia .) Z drugiej strony, jeśli ustawisz gadatliwość na Diagnostyka , otrzymasz następujące dane wyjściowe:

C: \ Program Files (x86) \ MSBuild \ 12.0 \ bin \ Microsoft.Common.CurrentVersion.targets (1697,5): ostrzeżenie MSB3245: Nie można rozwiązać tego odwołania. Nie można znaleźć zestawu „System.Web.Razor, Wersja = 3.0.0.0, Kultura = neutralny, PublicKeyToken = 31bf3856ad364e35, ProcessorArchitecture = MSIL”. Sprawdź, czy zespół istnieje na dysku. Jeśli kod wymaga tego odwołania, mogą pojawić się błędy kompilacji.

W rezultacie wszystko, co musisz zrobić, to:

1. Dodaj odniesienie do zestawu ręcznie (zlokalizuj je na dysku, być może GAC i dodaj jako odniesienie „bezpośrednie”) lub
2. Użyj pakietu NuGet (jeśli opublikowano go w galerii), aby go pobrać i odwołać się do zestawu w nim zawartego.

Więcej informacji o galerii NuGet tutaj . Więcej informacji o wstępnej kompilacji widoków ASP.NET tutaj .

Zmiana szczegółowości kompilacji w studiu wizualnym pomoże wskazać właściwy kierunek. Wykonaj poniższe kroki, aby zmienić gadatliwość w VS

1. Przejdź do menu Narzędzia-> Opcje w VS
2. Otwórz projekty i rozwiązania-> Kompiluj i uruchamiaj
3. Zmień wartość gadatliwości danych wyjściowych kompilacji projektu MSBuild. Wybierz jedną z Quiet, Minimal, Normal, DetailediDiagnostic

Sprawdź okno wyjściowe ( Ctrl+ Alt+ O) w VS, aby zobaczyć zmiany w dzienniku kompilacji.

i w jaki sposób sprawić, by ostrzeżenie zniknęło?

Prawdopodobnie będziesz musiał ponownie zainstalować lub zaktualizować pakiety NuGet, aby to naprawić.

Powtarzając jeden z komentarzy @elshev Kliknij prawym przyciskiem myszy rozwiązanie -> Zarządzaj pakietami NuGet dla rozwiązania -> W obszarze Konsoliduj możesz sprawdzić, czy istnieją różne wersje tego samego pakietu. Zaktualizuj tam pakiety. Błąd konfliktu został rozwiązany.

Korzystam z programu Visual Studio 2017 i napotkałem to podczas aktualizacji niektórych pakietów Nuget. To, co zadziałało, to otworzyć mój web.configplik, znaleźć <runtime><assemblyBinding>węzeł i go usunąć. Zapisz web.configi odbuduj projekt.

Spójrz w Error Listokno. Zobaczysz coś, co wygląda na bardzo długie ostrzeżenie o wiążących konfliktach. Kliknij dwukrotnie, a automatycznie odtworzy <runtime><assemblyBinding>blok z poprawnymi mapowaniami.

Jak stwierdzono w dotnet CLI wydanie 6583, problem powinien zostać rozwiązany za pomocą dotnet nuget locals --clear allpolecenia.

Mógłbym rozwiązać tę instalację Newtonsoft Json w projekcie sieciowym z pakietami samorodków

Oczywiście istnieje wiele różnych przyczyn, a zatem wiele rozwiązań tego problemu. Aby wrzucić mój do miksu, zaktualizowaliśmy zespół (System.Net.Http), do którego wcześniej bezpośrednio odwoływaliśmy się w naszym projekcie internetowym, do wersji zarządzanej przez NuGet. To usunęło bezpośrednie odniesienie w tym projekcie, ale nasz projekt testowy nadal zawierał bezpośrednie odniesienie. Uaktualnienie obu projektów do korzystania z zestawu zarządzanego przez NuGet rozwiązało problem.

Jeśli dokonałeś jakichkolwiek zmian w pakietach - ponownie otwórz sln. To zadziałało dla mnie!

Odkryłem, że czasami pakiety nuget zostaną zainstalowane (tak mi się wydaje) .NET Core wymaga wymaganych komponentów lub innych elementów, które są w konflikcie z już zainstalowanym frameworkiem. Moim rozwiązaniem było otwarcie pliku projektu (.csproj) i usunięcie tych odniesień. Na przykład System.IO, System.Threading i takie są zwykle dodawane, gdy Microsoft.Bcl jest dołączony przez jakiś niedawno zainstalowany pakiet NuGet. W moich projektach nie ma powodu, by niektóre wersje były takie, więc usuwam odwołania i kompilacje projektu. Mam nadzieję, że to pomaga.

Możesz przeszukać plik projektu pod kątem „referencji” i usunąć konflikty. Jeśli są zawarte w Systemie, pozbądź się ich, a kompilacja powinna działać. To może nie rozwiązać wszystkich przypadków tego problemu - upewniam się, że wiesz, co dla mnie zadziałało :)

Przykład tego, co skomentowałem:

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

Postępowałem zgodnie z radą kilku odpowiedzi tutaj, aby dowiedzieć się, co było nie tak, ale żadna z odpowiedzi nie wyjaśniła, jak to naprawić. Mój problem polegał na tym, że jedno odniesienie wymagało innej wersji drugiego odniesienia. Więc Newtonsoft był w wersji 6, ale niektóre inne biblioteki DLL chciały 4.5. Następnie zaktualizowałem Newtonsoft, jako jedną z innych sugerowanych odpowiedzi, co pogorszyło sytuację.

Więc faktycznie obniżyłem swoją instalację Newtonsoft i ostrzeżenie zniknęło (VS 2017):

Kliknij prawym przyciskiem myszy Referencje w eksploratorze rozwiązań i wybierz Zarządzaj pakietami NuGet ... Na karcie „Zainstalowane” znajdź Newtonsoft (lub inny konflikt) Po prawej stronie pojawi się menu rozwijane obok „Wersja”, które możesz zmienić na starsze wersje. Nie było dla mnie oczywiste, że to menu rozwijane można wykorzystać do obniżenia wersji.

Możesz uruchomić interfejs Dotnet CLI z pełną diagnostyczną szczegółowością, aby pomóc znaleźć problem.

dotnet run --verbosity diagnostic >> full_build.log

Po zakończeniu kompilacji możesz przeszukać plik dziennika (full_build.log) w poszukiwaniu błędu. Na przykład wyszukiwanie „konfliktu” powinno doprowadzić cię do problemu.

Odinstalowałem Microsoft ASP.NET MVC nuget.org z zarządzania NuGet Packagaes i ponownie go zainstalowałem. Podczas ponownej instalacji rozwiązał wszystkie konflikty związane z wersją maszynki do golenia. Spróbuj .

Zmieniłem gadatliwość MSBuild na Diagnostyczne. Ale nie mogłem znaleźć przyczyny problemu, więc zgodnie z powyższymi odpowiedziami miałem ten kod w 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>

Właśnie zmieniłem pierwszy System, Wersja z 4.0.0.0 na 12.0.0.0 i mój projekt działał.

Podobnie jak w przypadku innych odpowiedzi, ustaw poziom rejestrowania danych wyjściowych na szczegółowy i wyszukaj tam konflikty, które podpowiedzą, gdzie szukać dalej.

W moim przypadku odesłał mnie w kilku kierunkach, szukając źródła referencji, ale ostatecznie okazało się, że problem był jednym z moich przenośnych projektów bibliotek klas, celował w niewłaściwą wersję i wyciągał własną wersja referencji w, stąd konflikty. Szybki re-target i problem został rozwiązany.

Właśnie natrafiłem na to i problem po zmianie pakietu z nuget na lokalnie dlls dll. Problemem było stare powiązanie środowiska uruchomieniowego app.config.

Miałem to ostrzeżenie po migracji do Package Reference. W wyniku diagnostycznym znajdowała się informacja, że ​​do biblioteki odwołuje się sama biblioteka. Może to być błąd nowego odwołania do pakietu. Rozwiązaniem było włączenie AutoGenerateBindingRedirects i usunięcie niestandardowego przekierowania wiązania.

VS 2017, projekt MVC

Nie wiem dlaczego, ale dla mnie rozwiązaniem tego problemu było usunięcie outparametru z sygnatury metody modelowej, która została wywołana z metody akcji kontrolera. to jest bardzo dziwne zachowanie, ale to było rozwiązanie mojego problemu.

Uruchom Update-Packagepolecenie za pomocą konsoli Menedżera pakietów

To naprawi MSB3277, co zrobi, przeinstaluje wszystkie pakiety i wszystkie powiązane zestawy, z którymi pochodzą, do najwyższej możliwej wersji . Możliwe jest również zaktualizowanie konkretnego pakietu. Lub obniżenie wersji po aktualizacji, jeśli było to pożądane, ten naprawiony problem pojawił się dla mnie kilka razy. W zależności od liczby posiadanych pakietów nuget proces ten może potrwać kilka minut.

Więcej informacji na temat oficjalnych dokumentów https://docs.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages