Błąd CS1705: „który ma wyższą wersję niż zestaw przywoływany”

Przyglądałem się temu od jakiegoś czasu i nie udało mi się go rozwiązać. Otrzymuję następujący komunikat o błędzie:

Compiler Error Message: CS1705: Assembly 'My.Model, Version=1.1.4422.23773, Culture=neutral, 
PublicKeyToken=bfde95ba233094b2' uses 
'Common, Version=3.3.4273.24368, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 
which has a higher version than referenced assembly
'Common, Version=3.3.4269.17112, Culture=neutral, PublicKeyToken=bfde95ba233094b2'

c:\WINDOWS\assembly\GAC_MSIL\Common\3.3.4269.17112__bfde95ba233094b2\Common.dll: 
(Location of symbol related to previous error)

Na serwerze WWW działa serwer 2003. Poszedłem do c: \ windows \ assembly i zauważyłem, że na liście są 3 wersje pliku Common.dll. Najwyższa wymieniona wersja to 3.3.4269.17112

Skopiowałem dll z wersją: 3.3.4273.24368 do katalogu assemblera. Następnie ponownie skompilowałem i ponownie wdrożyłem mój kod (prawdopodobnie przesada, ale cóż). Gdy otworzyłem przeglądarkę w nowej sesji i ponownie przeszedłem do adresu URL witryny, nadal otrzymywałem ten sam komunikat.

Mogę użyć Eksploratora Windows i sprawdzić, czy na liście znajduje się również plik Common.dll z wyższą wersją.

Na co jeszcze mogę zwrócić uwagę, aby rozwiązać ten problem? Nie chcę zmieniać odwołania w moim zestawie, aby wskazywało na starszą wersję.

3 pomysły do ​​wypróbowania:

1. Upewnij się, że wszystkie Twoje biblioteki DLL są skompilowane z tą samą wersją Common.
2. Sprawdź, czy w rozwiązaniu znajdują się odwołania do projektu, a nie odwołania do plików.
3. Użyj przekierowań powiązań w swoim pliku web.config. ( Oryginalnie połączona wersja w Wayback Machine )

Wystąpił ten błąd, ponieważ polecenie „Odbuduj” tak naprawdę nie było odtwarzaniem.

Rozwiązanie: Zamknij program Visual Studio, naprawdę przejdź i usuń folder bin, a następnie odbuduj, może działać lepiej.

Czasami program Visual Studio kłamie na temat odwołań, więc sprawdź HintPathw swoich .csprojplikach.

Jeśli korzystasz z NuGet, warto przejść do `` Zarządzaj pakietami NuGet w celu rozwiązania '' , znaleźć pakiet, który powoduje problemy i trafić na aktualizację. Następnie powinien zaktualizować wszystkie pakiety do najnowszej wersji i rozwiązać problem.

Warto spróbować, ponieważ jest to szybkie i łatwe.

Mój problem polegał na tym, że miałem 2 projekty odwołujące się do 2 różnych kopii tego samego dll, które miały różne wersje. Naprawiłem to, usuwając je oba i upewniając się, że odwołują się do tego samego pliku dll.

Jedną z możliwych przyczyn jest to, że drugi zestaw jest instalowany w GAC, podczas gdy pierwszy zestaw o wyższym numerze wersji jest dodawany do odwołań projektu. Aby to sprawdzić, kliknij dwukrotnie zespół w odniesieniach do projektu i sprawdź, czy w przeglądarce obiektów jest inny zespół o tej samej nazwie.

W takim przypadku użyj narzędzia gacutil.exe do odinstalowania drugiego zestawu z GAC. Na przykład, jeśli są to zestawy 64-bitowe:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name>

Przejdź do Odniesienia i dodaj nowe odniesienie do pliku dll, który powoduje problem, i upewnij się, że wszystkie pliki DLL są kompilowane w tej samej wersji. To działa dla mnie, mam nadzieję, że działa również dla Ciebie.

Mój zespół właśnie napotkał ten problem w naszym środowisku kompilacji. Problem był spowodowany różnicą w elemencie <HintPath> pliku .csproj.

Nasz wspólny zestaw miał poprawną ścieżkę względną do katalogu zawierającego nasze zestawy referencyjne. Zależny zestaw miał ścieżkę z poprzedniej struktury katalogów. Rozwiązanie zostało pomyślnie skompilowane na maszynach deweloperskich, ponieważ GAC rozwiązał odwołanie osoby zależnej do poprawnej wersji zainstalowanej w C: \ Program Files. Środowisko kompilacji miało starszą instalację zestawu (mimo że nie powinno było jej mieć), do której powróciło, a tym samym błąd. Zaktualizowanie ścieżki <HintPath> w edytorze tekstu rozwiązało problem.

Problem jest widoczny, jeśli pakiety NuGet różnią się w wielu projektach w ramach rozwiązania.

Możesz to naprawić, aktualizując pakiety NuGet do wspólnej wersji ze wszystkimi PROJEKTAMI w rozwiązaniu

Miałem podobny problem. Mój problem polegał na tym, że miałem kilka projektów w ramach tego samego rozwiązania, z których każdy odwoływał się do określonej wersji biblioteki DLL, ale różnych wersji. Rozwiązaniem było ustawienie wartości „Określona wersja” na fałsz we wszystkich właściwościach wszystkich odniesień.

Wiem, że zadawano to jakiś czas temu, po wypróbowaniu niektórych z powyższych kroków. Pomogły mi następujące kroki i ten artykuł .

Znalazłem odniesienie i zmieniłem PublicKeyToken z tego, do którego się odwołujemy, na starszy.

Mam nadzieję, że to też pomoże.

Miałem ten sam błąd. Naprawiłem błąd po zainstalowaniu Microsoft.AspNetCore.ALLdo projektu testowego.

Folder kolekcji Handmade DLL
Jeżeli rozwiązanie ma folder śmieci do plików DLL z różnych bibliotek
lib, source, libs, itd.
Można dostać ten problem, jeśli będziesz otwierać swoje rozwiązanie (przez pewien czas jodły) w Visual Studio. W jakiś sposób brakuje folderu zbiorczego Twojej biblioteki dll lub brakuje konkretnego pliku dll.

Program Visual Studio spróbuje po cichu zastąpić odwołanie dll dla czegoś własnego. Jeśli VS się powiedzie, nowe odwołanie będzie trwałe dla twojego lokalnego rozwiązania. Nie dla innych klonów / kas.

Oznacza to, że Twój <HintPath>zostanie zignorowany, a plik projektu (.csproj) nie zostanie zmieniony.
Jako przykład mnie

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\lib\DocumentFormat.OpenXml.dll</HintPath>
</Reference>

DocumentFormat.OpenXmlBędzie odwoływać się od C:\Program Files (x86)\Open XML SDK\V2.5\libnie z solution\..\libfolderu.

szybkie obejście

• sprawdź i przywróć folder zbiorczy dll
• z Eksploratora rozwiązań zwolnij projekt , a następnie załaduj ponownie projekt .

Właściwe obejście polega na migracji do menedżera pakietów NuGet.

w przypadku programu SharePoint upewnij się, że w folderze głównym nie ma folderu „bin” z bibliotekami DLL, jeśli tak, po prostu go usuń. (i zmień „Copy Local” na false w VS).

Odnośniki w projekcie serwisu WWW są przechowywane w jego pliku web.config. Zaktualizuj tam odniesienie, aby naprawić błąd.

Spędziłem trochę czasu na przejrzeniu wszystkich odniesień w moim rozwiązaniu, zanim zdałem sobie sprawę, że zapomniałem o odniesieniach w pliku web.config.

Miałem ten sam problem z UnitTestingProject, gdzie w MainProject używałem „System.Web.Mvc, Version = 3.0.0.0”, aw UnitTestingProject używałem „System.Web.Mvc, Version = 3.0.0.1”

Zmień następujące elementy w <Reference Include="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <HintPath>..\packages\Microsoft.AspNet.Mvc.3.0.50813.1\lib\net40\System.Web.Mvc.dll</HintPath> </Reference>

Otrzymałem to po dodaniu Episerver Find do naszej witryny i zainstalowaniu odpowiedniego pakietu NuGet dla Episerver Find.

Poprawka była łatwa: zaktualizuj również wszystkie dodatki związane z Episerver (nawet jeśli wydają się niepowiązane: CMS, CMS.TinyMCE, CMS.UI itp.)

Po zaktualizowaniu wszystkich możliwych dodatków Episerver i ponownej kompilacji błąd zniknął.

W moim scenariuszu edytowałem plik .csproj dla mojej aplikacji dotnetCore. Zauważyłem, że tag TargetFramework ma wartość netcoreapp2.1, a tag RuntimeFrameworkVersion ma wartość 2.0.0 . Więc zmieniłem RuntimeFrameworkVersion na 2.1.0 , zapisałem, zrestartowałem VS i odbudowałem, a następnie rozwiązałem błędy.

Mam nadzieję, że to ci pomoże ...

Powodzenia,

Sugeshan

W swoim projekcie znajdź odniesienia System.Web.Mvc sprawdź wersję.

Następnie kliknij odnośniki prawym przyciskiem myszy -> assemblies i wyszukaj system.web.mvc i skonfiguruj .

Problem powoduje różne wersje tych zestawów .

Edycja: następnie wybierz opcję Zarządzaj pakietami NuGet i zainstaluj aktualizacje (jeśli masz wiele projektów, zainstaluj również aktualizacje).

Ważna aktualizacja to Microsoft.AspNet.Mvc i Microsoft.Net.Compilers nie zapomnij o tym!

W naszym zespole pracowaliśmy na różnych komputerach z git. Ktoś zaktualizował, dlla ja go nie miałem. Właśnie zaktualizowałem odniesienia do zależności i problem został rozwiązany.

Miałem podobny problem, utworzyłem bibliotekę DLL, tj. A.dll, która odwołuje się do innej biblioteki DLL, tj. B.dll.

Utworzyłem aplikację C.exe i odwołałem się do bibliotek DLL A.dll i B.dll.

Rozwiązanie - po usunięciu odniesienia do B.dll z c.exe udało mi się naprawić problem.

Mam nadzieję że to pomoże.