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ę.
źródło
*.*
numery wersji. Odbuduj wszystko, jedyny sposób, aby mieć pewność.Odpowiedzi:
3 pomysły do wypróbowania:
źródło
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ź
HintPath
w swoich.csproj
plikach.źródło
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.
źródło
csproj
edycji!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.
źródło
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:
źródło
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.
źródło
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.
źródło
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
źródło
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ń.
źródło
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.
źródło
Miałem ten sam błąd. Naprawiłem błąd po zainstalowaniu
Microsoft.AspNetCore.ALL
do projektu testowego.źródło
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
DocumentFormat.OpenXml
Będzie odwoływać się odC:\Program Files (x86)\Open XML SDK\V2.5\lib
nie zsolution\..\lib
folderu.szybkie obejście
Właściwe obejście polega na migracji do menedżera pakietów NuGet.
źródło
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).
źródło
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.
źródło
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>
źródło
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ął.
źródło
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
źródło
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!
źródło
W naszym zespole pracowaliśmy na różnych komputerach z git. Ktoś zaktualizował,
dll
a ja go nie miałem. Właśnie zaktualizowałem odniesienia do zależności i problem został rozwiązany.źródło
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.
źródło