Rozwiązywanie konfliktów MSB3247-Found pomiędzy różnymi wersjami tego samego zależnego zespołu

Mike Hadlow napisał małą aplikację konsolową o nazwie AsmSpy , która dość ładnie wymienia odwołania do każdego zestawu:

Reference: System.Net.Http.Formatting
        4.0.0.0 by Shared.MessageStack
        4.0.0.0 by System.Web.Http

Reference: System.Net.Http
        2.0.0.0 by Shared.MessageStack
        2.0.0.0 by System.Net.Http.Formatting
        4.0.0.0 by System.Net.Http.WebRequest
        2.0.0.0 by System.Web.Http.Common
        2.0.0.0 by System.Web.Http
        2.0.0.0 by System.Web.Http.WebHost

Jest to znacznie szybszy sposób, aby dostać się na sam dół Ostrzeżenia MSB3247, niż zależeć od wyjścia MSBuild.

Stwierdziłem, że (przynajmniej w Visual Studio 2010) trzeba ustawić dokładność wyjściową na co najmniej szczegółową, aby móc wykryć problem.

Może być tak, że moim problemem było odniesienie, które wcześniej było odniesieniem GAC, ale nie było to już po ponownej instalacji mojego komputera.

Czasami @AMissico odpowiedź nie wystarczy. W moim przypadku nie mogłem znaleźć błędu w oknach wyjściowych, więc postanowiłem utworzyć plik dziennika i przeanalizować go, wykonując następujące kroki:

1. Zapisanie dziennika budowy do pliku... https://msdn.microsoft.com/en-us/library/ms171470.aspx

   msbuild MyProject.proj /fl /flp:logfile=MyProjectOutput.log;verbosity=detailed

2. Znajdź tekst: warning MS... lub szczegółowe informacje o ostrzeżeniu: (np. linia 9293) Found conflicts between different versions..., a pełne szczegóły błędu konfliktu znajdą się powyżej tej wiadomości (np. linia 9277) There was a conflicts between...

Visual Studio 2013

To Ostrzeżenie wygenerowane dla domyślnego ASP.NET MVC 4 beta zobacz tutaj

W, każdy rzut tego ostrzeżenia można wyeliminować ręcznie edytując .plik csproj dla Twojego projektu.

Modyfikuj........: Reference Include= "System. Net. Http"

Do przeczytania ......: Reference Include= "System. Net. Http, Version = 4.0.0.0"

Użyj czytnika zależności

Używając dep.exe możesz wypisać wszystkie zagnieżdżone zależności całego folderu. W połączeniu z narzędziami uniksowymi, takimi jak grep lub awk, może pomóc rozwiązać twój problem]}

Znajdowanie zestawów odwołujących się do więcej niż jednej wersji

$ dep | awk '{ print $1 " " $2; print $4 " " $5 }' | awk '{ if (length(versions[$1]) == 0) versions[$1] = $2; if (versions[$1] != $2) errors[$1] = $1; }  END{ for(e in errors) print e } ' 
System.Web.Http            

Ta niejasna linia poleceń uruchamia dep.exe następnie wyprowadza wyjście dwa razy do awk do

• umieść rodzica i dziecko w jednej kolumnie (domyślnie każda linia zawiera jednego rodzica i dziecko aby wyrazić fakt, że ten rodzic zależy od tego dziecka)
Następnie wykonaj rodzaj 'group by' używając tablicy asocjacyjnej

Zrozumienie, jak to zgromadzenie zostało wciągnięte do twojego Kosza

$ dep myproject/bin | grep -i System\.Web\.Http
MyProject-1.0.0.0 >> System.Web.Http.Web-5.2.3.0 2 ( FooLib-1.0.0.0 )
MyProject-1.0.0.0 >> System.Web.Http.Web-4.0.0.0 2 ( BarLib-1.0.0.0 )
FooLib-1.0.0.0 > System.Web.Http.Web-5.2.3.0 1
BarLib-1.0.0.0 > System.Web.Http.Web-4.0.0.0 1 

W tym przykładzie narzędzie pokaże ci ten System.Www.Http 5.2.3 pochodzi z Twojej zależności do FooLib, podczas gdy Wersja 4.0.0 pochodzi z BarLib.

Wtedy masz wybór pomiędzy

• przekonywanie właścicieli libs do korzystania z tego samego wersja
• przestań używać jednego z nich
• dodawanie przekierowań wiążących w pliku konfiguracyjnym, aby korzystać z najnowszej wersji

Jak uruchomić te rzeczy w Windows

Jeśli nie masz powłoki typu unix, musisz ją pobrać, zanim będziesz mógł uruchomić awk i grep. Wypróbuj jedną z następujących opcji

• cmder + awk + dep.exe
• gitbash + awk + dep.exe
• cygwin + dep.exe

Miałem ten sam błąd i nie mogłem go rozgryźć z innymi odpowiedziami. Odkryłem, że możemy "skonsolidować" pakiety NuGet.

1. Kliknij prawym przyciskiem myszy rozwiązanie
2. Kliknij Zarządzaj Pakietami Nuget
3. Konsolidacja karty i aktualizacja do tej samej wersji.

Ja też miałem ten problem i też skorzystałem z porad AMissico (chociaż musiałem ustawić poziom szczegółowości na szczegółowy.

Problem był właściwie całkiem prosty, chociaż po znalezieniu winowajcy.

Tło: Uaktualniłem mój projekt z VS2008 do VS2010. W VS2008 docelowy framework był 3.5 i kiedy wprowadziłem go do VS2010 zmieniłem go na 4 (Full). Zaktualizowałem również niektóre komponenty stron trzecich, w tym Crystal reports.

Okazało się, że większość Odniesienia do systemu, gdzie wskazuje na wersję 4.0.0.0, ale para nie została automatycznie zmieniona (System i System.Www.Usługi) i nadal patrzyli na 2.0.0.0. Crystal reports odwołuje się do 4.0.0.0 i tak to było miejsce, w którym występowały konflikty. Po prostu umieszczenie kursora w pierwszej bibliotece systemowej w Eksploratorze rozwiązań, kursor w dół listy i szukanie jakichkolwiek odniesień do 2.0.0.0, usunięcie i ponowne dodanie nowszej wersji 4.0.0.0 załatwiło sprawę.

The strange this was that większość referencji została poprawnie zaktualizowana i gdyby nie Crystal reports, prawdopodobnie nigdy bym tego nie zauważył...

Złożyłem wniosek na podstawie Mike Hadlow application: AsmSpy.

Moja aplikacja jest aplikacja WPF z GUI i można pobrać z mojego domowego serwera: AsmSpyPlus.exe .

Kod jest dostępny pod adresem: GitHub

Jak wspomniano tutaj, musisz usunąć nieużywane odwołania i ostrzeżenia znikną.

ASP.NET menedżer budowania buduje stronę internetową, przechodząc przez foldery Alfabetycznie, a dla każdego folderu oblicza zależności i buduje zależności najpierw, a następnie wybrany folder.

W tym przypadku problematyczny folder, jakim jest ~ / Controls, jest wybrany do zbudowania na początku, z jeszcze nieznanego powodu, buduje tam niektóre kontrolki jako oddzielny zespół zamiast wewnątrz tego samego zespołu co inne kontrolki (wydaje się być podłączony do fakt, że niektóre kontrolki są zależne od innych kontrolek w tym samym folderze).

Następnie następny folder, który jest zbudowany (~/File-Center/ Control) jest zależny od folderu głównego~/, który jest zależny od ~/Controls, więc folder ~ / Controls jest budowany ponownie tylko tym razem kontrolki, które zostały oddzielone do ich własnego zestawu są teraz połączone do tego samego zestawu, co inne kontrolki z oddzielonym zespołem nadal odwołuje.

Więc w tym punkcie 2 assembly (przynajmniej) mają te same kontrolki i Kompilacja nie powiedzie się.

Chociaż nadal nie wiemy, dlaczego tak się stało, udało nam się obejść to zmieniając nazwę folderu Controls na zcontrols, w ten sposób nie jest on zbudowany przed ~/file-Center/Control, tylko po i w ten sposób jest zbudowany tak, jak powinien.

Quick Fix:

Kliknij prawym przyciskiem myszy na solution - > Manage NuGet packages for solution - > Under Consolidate możesz zobaczyć, czy istnieją różne wersje tego samego pakietu, które zostały zainstalowane. Odinstaluj różne wersje i zainstaluj najnowszą.

Najprostszy sposób bez uwzględnienia (wewnętrznych) zależności:

1. Otwórz "Solution Explorer".
2. Kliknij na "Pokaż wszystkie pliki"
3. Rozwiń "Referencje"
4. zobaczysz jeden(lub więcej) odnośnik (ów) z nieco inną ikoną niż reszta. Zazwyczaj jest z żółtym pudełkiem sugerującym, abyś to odnotował. Po prostu to Usuń.
5. Dodaj referencję i skompiluj swój kod.
To wszystko.

W moim przypadku było problem z MySQL reference. Jakoś mogłem wymienić trzy jego wersje pod listą wszystkich dostępnych referencji. Postępowałem zgodnie z procesem od 1 do 6 powyżej i to działało dla mnie.

Visual Studio for Mac dodatek społeczności:

Ponieważ odpowiedź AMissico wymaga zmiany poziomu dziennika i ani ASMSpy, ani ASMSpyPlus nie są dostępne jako rozwiązanie wieloplatformowe, oto krótki dodatek do Visual Studio dla Mac:

Https://docs.microsoft.com/en-us/visualstudio/mac/compiling-and-building

Jest w społeczność Visual Studio → Preferencje... → Projekty → Build Log → verbosity