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

371

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?

Chłodnica wody v2
źródło
2
Zobacz także ... stackoverflow.com/questions/1871073/
SteveC
2
Przesłałem

Odpowiedzi:

513

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 :)

Ruben Bartelink
źródło
3
Dzięki - korzystam z programu Visual Studio od wielu lat i nigdy nie miałem problemu, który wymagałby zagłębiania się tak głęboko w dziennik kompilacji. Inny problem, ale uświadomienie sobie, że informacja, której szukałem, była gdzieś emitowana, rozwiązało mój problem.
Timothy Lee Russell,
4
Wygląda na to, że szczegółowy poziom dziennika działa wewnątrz VS (więc nie jest wymagana diagnostyka). Nie byłby to jednak pierwszy raz, gdy MSBuild zachowuje się inaczej w VS ...
Johannes Rudolph,
105
Aby zmienić szczegółowość dziennika z menu Narzędzia-> Opcje, a następnie znajdź Projekt i rozwiązania-> Kompiluj i uruchamiaj
Jenn
3
W moim przypadku miałem trzy konflikty, a jeden z nich był odpowiedzialny za pozostałe dwa. Skopiowałem mój „szczegółowy” dziennik kompilacji do Notatnika, szukałem „konfliktu”, zaktualizowałem pakiet NuGet o referencję, którą rozpoznałem, i problem został rozwiązany.
Isaac Lyman
@robotnik Dziękuję za sugestię edycji [której odmówili inni]. W rzeczywistości zamieściłem informacje na dole odpowiedzi, ale mam nadzieję, że obecna odpowiedź jest tak jasna, jak zamierzałeś.
Ruben Bartelink
76

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]
Ilya Kozhevnikov
źródło
10
Skończyłem przesyłanie tej komendy do pliku dziennika, dzięki czemu mogłem łatwiej ją przejrzeć:msbuild "Foo.sln" /t:Rebuild /v:d > build.log
CrazyPyro
2
Najlepszy sposób na dotarcie do terminala: stackoverflow.com/a/22702405/268066
CrazyPyro
@CrazyPyro msbuild ma „wbudowaną” rurkę - /l:FileLogger,Microsoft.Build.Engine;logfile=build.log- zwróć uwagę na wyjaśnienia dotyczące przełączników tutaj
drzaus
3
Gdzie znajduje się „dziennik kompilacji”? Jak to znaleźć?
Więzień ZERO
Ta odpowiedź pokazuje, jak uzyskać więcej szczegółów z msbuild, o co dba użytkownik mono. Wszystkie pozostałe odpowiedzi zakładają, że używasz VS i działasz w środowisku Windows.
Bezwarunkowo Przywróć
39

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

wprowadź opis zdjęcia tutaj

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 .

Alexander Christov
źródło
W VS 2017, gdy ustawiłem „Szczegółowość danych wyjściowych kompilacji projektu MSBuild” (nie plik dziennika) na Szczegółowy (nie Diagnostyczny), w oknie Wyjścia pojawił się błąd „Nie można zlokalizować zestawu”.
ALEXintlsos
@ALEXintlsos: najwyraźniej ta funkcjonalność uległa zmianie; nadal masz błąd gdziekolwiek to jest - postępuj zgodnie z instrukcjami, aby się go pozbyć.
Alexander Christov
22

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.

sree
źródło
16

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

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

CrazyPyro
źródło
2
To, w połączeniu z ponownym uruchomieniem programu Visual Studio, gdy odmówił on ponownej instalacji pakietu, rozwiązało problem.
Ohad Schneider,
22
Najprostszy sposób na sprawdzenie: Kliknij prawym przyciskiem myszy rozwiązanie -> Manage NuGet packages for solution-> Pod Consolidate
spodem
16

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.

Shaswat Rungta
źródło
1
to mi nie rozwiązało. Musiałem odinstalować Newtonsoft.JSON i zainstalować ponownie za pomocą NuGet. To zaktualizowane zależności od innych pakietów.
Garr Godfrey,
Zdarzyło mi się to również podczas korzystania z narzędzi takich jak Resharper, które automatycznie dodają brakujące odwołania do DLL. Dobrym pomysłem może być tutaj „Zawsze dodawaj za pomocą nugetu”.
Shaswat Rungta
Dla mnie to nie działa, ponieważ odinstalowanie pakietu próbuje wykonać kompilację, co nie może nastąpić, ponieważ występuje konflikt pakietów. Więc nie jestem nawet w stanie ponownie zainstalować pakietu :(
nickornotto
8

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.

RandomHandle
źródło
6

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

Jose L. Garcia
źródło
1
To mi nie zadziałało; sytuacja była taka sama po uruchomieniu polecenia.
Zimano
3

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

Karolina
źródło
3

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.

joelmdev
źródło
2

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

Naumaan Shaikh
źródło
1

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

Auri Rahimzadeh
źródło
1

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.

Andrzej
źródło
1

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.

Książę Owen
źródło
0

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 .

jitendra r
źródło
0

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ł.

Pantelitsa Mavrovounioti
źródło
0

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.

car1bo
źródło
0

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.

Tom Makin
źródło
0

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.

raV720
źródło
0

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.

jonathana
źródło
-2

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

Aistis Taraskevicius
źródło
14
Ta rada może zrujnować Twój dzień, jeśli nie chcesz najnowszych pakietów, co często ma miejsce w przypadku kodu produkcyjnego.
Tony O'Hagan,
1
Jest to wskazane w poradach, a to, co może być dla Ciebie problemem, jest bezpiecznym i łatwym sposobem na rozwiązanie problemu, więc proszę, nie oddawaj głosu osobom z własnej opinii.
Aistis Taraskevicius
1
To rozwiązanie nie działało dla mnie. Miałem już wszystkie najnowsze wersje.
Zero3
@ Zero3, czy uruchomiłeś go z najlepszego rozwiązania, nie określając bezpośrednio żadnego pakietu, zwykle działa, ponieważ ponownie instaluje każdy z nich i aktualizuje referencje, co powoduje niedopasowania
Aistis Taraskevicius,
3
To naprawdę okropna rada. To nie jest opinia, aktualizacja pakietów psuje kod, jeśli nie zostanie to zrobione celowo.
TheBatman