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

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

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

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!

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.

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.

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.

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

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>

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]

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.

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

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.

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

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!

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.

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.

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

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.

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

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