Ostrzeżenie: znaleziono konflikty między różnymi wersjami tego samego zależnego zestawu

320

Obecnie rozwijam aplikację .NET, która składa się z 20 projektów. Niektóre z tych projektów są kompilowane przy użyciu .NET 3.5, inne są nadal projektami .NET 2.0 (jak dotąd żaden problem).

Problem polega na tym, że jeśli dołączę komponent zewnętrzny, zawsze pojawia się następujące ostrzeżenie:

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

Co dokładnie oznacza to ostrzeżenie i czy może istnieć możliwość wyłączenia tego ostrzeżenia (np. Użycie #pragma disable w plikach kodu źródłowego)?

ollifant
źródło

Odpowiedzi:

410

To ostrzeżenie oznacza, że ​​dwa projekty odnoszą się do tego samego zestawu (np. System.Windows.Forms), Ale dwa projekty wymagają różnych wersji. Masz kilka opcji:

  1. Ponownie skompiluj wszystkie projekty, aby używać tych samych wersji (np. Przenieś wszystkie do .Net 3.5). Jest to preferowana opcja, ponieważ cały kod działa z wersjami zależności, z którymi zostały skompilowane.

  2. Dodaj wiążące przekierowanie . Spowoduje to usunięcie ostrzeżenia. Jednak projekty .Net 2.0 będą (w czasie wykonywania) powiązane z wersjami .Net 3.5 zestawów zależnych, takich jak System.Windows.Forms. Możesz szybko dodać przekierowanie wiązania, klikając dwukrotnie błąd w Visual Studio.

  3. Zastosowanie CopyLocal=true. Nie jestem pewien, czy to stłumi ostrzeżenie. Będzie to, podobnie jak opcja 2 powyżej, oznaczać, że wszystkie projekty będą używać wersji System.Windows.Forms .Net 3.5.

Oto kilka sposobów zidentyfikowania przestępczych referencji:

  • Możesz użyć narzędzia, takiego jak to znalezione na https://gist.github.com/1553265
  • Inną prostą metodą jest ustawienie budowania gadatliwości wyjściowej (Narzędzia, Opcje, Projekty i Rozwiązania, budowanie i uruchamianie, gadatliwość wyjściowej budowania projektu MSBuild, Szczegółowa), a po zbudowaniu przeszukaj okno wyjściowe w poszukiwaniu ostrzeżenia i spójrz na tekst tuż nad nim . (Czapka dla Pauloya, który zasugerował to w komentarzach do tej odpowiedzi) .
Brian Low
źródło
9
Tylko jeden szybki sposób na znalezienie go bez narzędzia - jeśli dodasz przekierowanie wiązania (jako opcja 2), wyświetli się odnośnik (odnośniki) - w razie potrzeby możesz użyć jednej z pozostałych metod aby to obsłużyć i usuń przekierowania z pliku konfiguracyjnego.
Brisbe
222
Najprostszym sposobem na znalezienie „obraźliwych odniesień” jest ustawienie gadatliwości wyjściowej kompilacji (Narzędzia, Opcje, Projekty i Rozwiązania, kompilacja i uruchomienie, gadatliwość wyjściowa kompilacji projektu MSBuild, Szczegółowa) i po zbudowaniu, przeszukaj okno wyników za ostrzeżenie. Zobacz tekst tuż nad nim.
pauloya,
7
Powiązanie przekierowania poprzez ostrzeżenie podwójnym kliknięciem (krok 2) nie usuwa mojego ostrzeżenia. Widzę app.config dodany do zestawu, który, jak podejrzewam, jest przyczyną, ale ostrzeżenie jest nadal wyświetlane po wyczyszczeniu / przebudowie. Próbowałem także krok 3 dodatkowo, bez powodzenia. Jakieś pomysły?
angularsen
9
Co jeśli nie są referencjami z twoich własnych projektów? Na przykład, odwołuje się projekt, który ma zależność Newtonsoft.Json, Version = 6.0.0.0, i odwołuje kolejny projekt, który ma uzależnienia od Newtonsoft.Json, Version = 4.5.0.0
Edward Ned Harvey
3
@ brian-low, czy mogę zasugerować dodanie ustawienia szczegółowości kompilacji wyjściowej (zgodnie z sugestią @pauloya) jako opcji w odpowiedzi obok powiązanego narzędzia? (Zastrzeżenie, faktycznie próbowałem edytować odpowiedź, aby to zrobić, ale została odrzucona po sprawdzeniu :))
Rick Riensche
44

Zasadniczo dzieje się tak, gdy w zestawach, do których się odwołujesz, ustawiono opcję „Kopiuj lokalnie” na „Prawda”, co oznacza, że ​​kopia biblioteki DLL jest umieszczana w folderze bin wraz z plikiem exe.

Ponieważ program Visual Studio skopiuje również wszystkie zależności zestawu, do którego istnieje odwołanie, możliwe jest, że zostaną wyświetlone dwie różne wersje tego samego zestawu. Jest to bardziej prawdopodobne, jeśli twoje projekty są w osobnych rozwiązaniach i dlatego można je skompilować osobno.

Ominąłem to, ustawiając opcję Kopiuj lokalnie na False dla odniesień w projektach składania. Zrób to tylko w przypadku plików wykonywalnych / aplikacji internetowych, w których potrzebujesz zestawu do uruchomienia gotowego produktu.

Mam nadzieję, że to ma sens!

Matt Hamilton
źródło
31

Chciałem opublikować rozwiązanie Pauloyi podane w komentarzach powyżej. Uważam, że jest to najlepsze rozwiązanie do znajdowania obrażających referencji.

Najprostszym sposobem na znalezienie „obraźliwych odniesień” jest ustawienie gadatliwości wyników kompilacji (Narzędzia, Opcje, Projekty i Rozwiązania, kompilacja i uruchomienie, gadatliwość wyników budowania projektu MSBuild, Szczegółowa) i po zbudowaniu, przeszukaj okno wyników za ostrzeżenie. Zobacz tekst tuż nad nim.

Na przykład podczas wyszukiwania w panelu wyników „konfliktu” możesz znaleźć coś takiego:

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.

Jak widać, istnieje konflikt między wersjami EF 5 i 6.

użytkownik1477388
źródło
3
Ale teraz, gdy mam te informacje, jak usunąć błąd? Widzę, na czym polega konflikt, ale nie mogę znaleźć, gdzie projekt odwołuje się do wersji
powodującej
Cześć @Bassie, pierwszą rzeczą do zrobienia byłoby sprawdzenie pliku pakietu nuget i ustalenie, czy należy zaktualizować wszystkie pliki do tej samej wersji pakietu. Możesz to zrobić, uruchamiając polecenie podobne do update-package [your package name] -version 6.0.0 -reinstall
opisanego w
@Bassie, możesz zrobić to, co sugeruje ostrzeżenie, i dodać przekierowanie wiązania do pliku app.config! (jeśli aktualizacja nie jest opcją).
BrainSlugs83
@Bassie zobacz moją odpowiedź, gdzie pokazuję, jak zdobyć różne zestawy / .dll, które powodują problemy z niedopasowaniem.
newprint
22

Miałem ten sam problem z jednym z moich projektów, jednak żaden z powyższych nie pomógł rozwiązać ostrzeżenia. Sprawdziłem szczegółowy plik dziennika kompilacji, użyłem AsmSpy do sprawdzenia, czy użyłem poprawnych wersji dla każdego projektu w rozwiązaniu, którego dotyczy problem, dwukrotnie sprawdziłem rzeczywiste wpisy w każdym pliku projektu - nic nie pomogło.

W końcu okazało się, że problemem była zagnieżdżona zależność jednego z odniesień, które miałem w jednym projekcie. To odniesienie (A) z kolei wymagało innej wersji (B), do której odwoływałem się bezpośrednio ze wszystkich innych projektów w moim rozwiązaniu. Aktualizacja referencji w referencyjnym projekcie rozwiązała go.

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)

Mam nadzieję, że powyższe pokazuje, co mam na myśli, zajęło mi kilka godzin, aby się dowiedzieć, więc mam nadzieję, że ktoś inny również skorzysta.

Gorgsenegger
źródło
1
Mam ten sam problem. Nie mam jednak szansy zaktualizować odwołania do nowszej wersji. Próbowałem za pomocą App.config: chociaż działa dla aplikacji, Visual Studio 2010 wydaje się ignorować podczas kompilacji.
Thomas Weller,
1
wow, miałem te problemy od dwóch miesięcy i nie mogłem znaleźć i rozwiązać. Z jakiegoś powodu zawiesiłby się tylko podczas debugowania, aw niektórych przypadkach ręcznie zastąpiłby kłopotliwy plik .dll rzeczywistym plikiem w folderze bin. Debugowanie było prawdziwym bólem. Kiedy przeczytałem twoją odpowiedź, zdałem sobie sprawę, że to właśnie się ze mną dzieje i naprawiłem to w około 5 minut :)
Dennis Puzak
19

W Visual Studio, jeśli klikniesz prawym przyciskiem myszy rozwiązanie i Zarządzaj pakietami nugetów, pojawi się karta „Konsoliduj” , która ustawia wszystkie pakiety w tej samej wersji.

Tiago Gouvêa
źródło
Dzięki za wskazówkę. Tym razem mi to nie pomogło, ale dobrze wiedzieć, że tam jest.
BrainSlugs83,
8

Właśnie dostałem ten komunikat ostrzegawczy, wyczyściłem rozwiązanie i ponownie skompilowałem (Kompilacja -> Wyczyść rozwiązanie) i zniknęło.

MoMo
źródło
9
Tylko do czasu, aż przebudujesz rozwiązanie
Luke
To mnie ratuje! Próbowałem innego rozwiązania od wczoraj, ale to rozwiązało mój problem. Łącznie z komentarzem powyżej tego ^. Dzięki!
vnpnlz
6

Miałem ten sam problem i rozwiązałem go, zmieniając następujące elementy w pliku web.config.

Zdarzyło mi się, ponieważ uruchamiam aplikację za pomocą Newtonsoft.Json 4.0

Od:

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

Do:

<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>
Phil50
źródło
To było dla mnie rozwiązanie. Miałem wiążące przekierowanie do wyższej wersji i zadziałało to dopiero po przejściu do niższej wersji.
mrwaim
1
dlaczego? To dla mnie dziwne. Nie używam EF, ale myślałem, że zawsze chcemy przejść do ostatniej wersji?
Hoàng Long,
1
@ HoàngLong, ponieważ wersja, do której się odwołujesz, jest starszą wersją, ale wersja, którą dołączasz, jest nowsza.
BrainSlugs83
3

Mam inny sposób na zrobienie tego, jeśli używasz Nuget do zarządzania swoimi zależnościami. Odkryłem, że czasami VS i Nuget nie pasują do siebie, a Nuget nie jest w stanie rozpoznać, że twoje projekty nie są zsynchronizowane. Package.config powie jedno, ale ścieżka pokazana w Odnośniki - Właściwości wskaże coś innego.

Jeśli chcesz zaktualizować swoje zależności, wykonaj następujące czynności:

  1. W Solution Explorer kliknij prawym przyciskiem myszy Projekt i kliknij „Zarządzaj pakietami Nuget”

  2. Wybierz zakładkę „Zainstalowane pakiety” w lewym okienku. Nagrywaj zainstalowane pakiety. Jeśli masz dużo, możesz najpierw skopiować swoje pakiety.config na pulpit, abyś mógł sprawdzić je z Google, aby zobaczyć, które pakiety Nuget są zainstalowane

  3. Odinstaluj swoje pakiety. Jest OK, dodamy je od razu.

  4. Natychmiast zainstaluj potrzebne pakiety. To, co zrobi Nuget, to nie tylko uzyskanie najnowszej wersji, ale zmiana twoich referencji, a także dodanie dla ciebie przekierowań wiążących.

  5. Zrób to dla wszystkich swoich projektów.

  6. Na poziomie rozwiązania wykonaj Wyczyść i Odbuduj.

Możesz zacząć od niższych projektów i przejść do projektów na wyższym poziomie, a następnie odbudowywać każdy projekt.

Jeśli nie chcesz aktualizować swoich zależności, możesz użyć konsoli menedżera pakietów i użyć składni Update-Package -ProjectName [yourProjectName] [packageName] -Version [versionNumber]

Rachunek
źródło
2

To zależy od twojego zewnętrznego komponentu. Odwołanie do zewnętrznego komponentu w aplikacji .NET generuje identyfikator GUID w celu identyfikacji tego komponentu. Ten błąd występuje, gdy komponent zewnętrzny, do którego odwołuje się jeden z twoich projektów, ma tę samą nazwę, ale inną wersję niż inny taki komponent w innym zestawie.

Zdarza się to czasami, gdy używasz „Przeglądaj”, aby znaleźć odniesienia i dodać niewłaściwą wersję zestawu lub masz inną wersję komponentu w repozytorium kodu niż ta, którą zainstalowałeś na komputerze lokalnym.

Spróbuj znaleźć, które projekty powodują te konflikty, usuń komponenty z listy referencyjnej, a następnie dodaj je ponownie, upewniając się, że wskazujesz ten sam plik.

Jon Limjap
źródło
2

=> sprawdź, czy aplikacja zostanie częściowo zainstalowana.

=> przede wszystkim odinstaluj tę instancję z aplikacji odinstalowującej.

=> następnie wyczyść, przebuduj i spróbuj wdrożyć.

to rozwiązało mój problem. mam nadzieję, że to też pomaga. Z poważaniem.

Neelam Prajapati
źródło
1

Miałem także ten problem - w moim przypadku był on spowodowany przez ustawienie właściwości „Określona wersja” w wielu odniesieniach na wartość true. Zmiana na false w tych referencjach rozwiązała problem.

Tristan Lewis
źródło
1

Jeśli korzystam z NuGet, wszystko co musiałem zrobić to:

  1. kliknij prawym przyciskiem myszy projekt i kliknij Zarządzaj pakietami NuGet.

  2. kliknij trybik w prawym górnym rogu

  3. kliknij kartę Ogólne w Menedżerze pakietów NuGet nad Źródłami pakietów

  4. zaznacz „Pomiń stosowanie przekierowań powiązań” w Przekierowaniach powiązań

  5. Wyczyść i odbuduj, a ostrzeżenie zniknęło

Bułka z masłem

0tombo0
źródło
1

Właśnie spędziłem trochę czasu debugując ten sam problem. Zauważ, że ten problem może nie dotyczyć różnych projektów, ale w rzeczywistości między kilkoma referencjami w jednym projekcie, które zależą od różnych wersji tego samego dll / zestawu. W moim przypadku problemem było odniesienieFastMember.dll niedopasowanie wersji które pochodzi z dwóch różnych pakietów NuGet w jednym projekcie. Kiedy dostałem projekt, nie skompiluje się, ponieważ brakuje pakietów NuGet, a VS odmówił przywrócenia brakujących pakietów. Za pomocą menu NuGet ręcznie aktualizuję wszystkie NuGety do najnowszej wersji, czyli wtedy, gdy pojawiło się ostrzeżenie.

W Visual Studio Tools > Options > Build and Run > MSBuld Project build output verbosity: (set to) Diagnostics.Poszukaj linii There was a conflict betweenw Outputoknie. Poniżej znajduje się część wyników, którą otrzymałem:

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)

Zauważ, że 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.dllpochodzi z ClosedXMLNuGet i zależy od tego FastMember.dll 1.3.0.0. Na FastMemberdodatek w projekcie jest także Nuget i tak też jest FastMember.dll 1.5.0.0. Niedopasowanie!

Odinstalowałem ClosedXMLi FastMemberNuGets, ponieważ miałem przekierowanie wiązania i zainstalowałem najnowszą wersję, ClosedXMLktóra naprawiła problem!

nowy odcisk
źródło
0

To mi się też przydarzyło. Do jednego dll przywołano dwukrotnie: raz bezpośrednio (w referencjach) i raz pośrednio (do których odwołuje się inny projekt, do którego odwołuje się). Usunąłem bezpośrednie odniesienie, wyczyściłem i przebudowałem rozwiązanie. Problem rozwiązany.

Igor Gorjanc
źródło
0
  1. Otwórz „Solution Explorer”.
  2. Kliknij „Pokaż wszystkie pliki”
  3. Rozwiń „Referencje”
  4. Zobaczysz jeden (lub więcej) odnośników z nieco inną ikoną niż reszta. Zazwyczaj jest to żółte pole sugerujące zanotowanie go. Po prostu to usuń.
  5. Dodaj referencję i skompiluj kod.
  6. To wszystko.

W moim przypadku wystąpił problem z referencją MySQL. Jakoś mógłbym wymienić trzy jego wersje pod listą wszystkich dostępnych referencji; dla .net 2.0, .net 4.0 i .net 4.5. Postępowałem zgodnie z powyższą procedurą od 1 do 6 i zadziałało to dla mnie.

Sukhi
źródło
0

Kolejną rzeczą do rozważenia i sprawdzenia jest upewnienie się, że nie masz uruchomionej usługi korzystającej z tego folderu bin. jeśli ich, to zatrzymaj usługę i przebuduj rozwiązanie

Telwa Gangnam
źródło
0

Wydaje się, że jest problem w Mac Visual Studio podczas edycji plików .resx. Naprawdę nie wiem, co się stało, ale dostałem ten problem, gdy tylko edytowałem niektóre pliki .resx na komputerze Mac. Otworzyłem projekt w systemie Windows, otworzyłem pliki i były tak, jakby nie były edytowane. Zredagowałem je, zapisałem i wszystko znów zaczęło działać na Macu.

Dpedrinha
źródło
0

Miałem taki problem, gdy mój projekt zawierał odwołanie do NETStandardLibrary i jeden z zestawów referencyjnych został opublikowany dla Netcore. Właśnie opublikowałem go jako standard sieci i problem zniknął

Jacek Plesnar
źródło
0

Oto rozwiązanie w stylu .NET Core 3.0: https://github.com/HTD/ref-check

Gdy znajdziesz jakieś konflikty, być może uda ci się je rozwiązać. Jeśli sprzeczne odniesienia pochodzą z innych pakietów, albo nie masz szczęścia, albo zamiast tego musisz użyć źródeł.

W moim przypadku konflikty pakietów są często moje, więc mogę naprawić problemy z zależnościami i ponownie je opublikować.

Złupić
źródło