Błąd CS1705: "który ma wyższą wersję niż zespół referencyjny"

Question

Już się nad tym zastanawiałem i nie udało mi się go rozwiązać. Pojawia się 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) 

Serwer WWW jest uruchomiona Server 2003. Poszedłem do C: \ Windows \ assembly i rzeczywiście powiadomienia, że ​​były 3 wersje Common.dll wymienione. Najwyższa wymieniona wersja to 3.3.4269.17112

Skopiowałem bibliotekę DLL z wersją 3.3.4273.24368 do katalogu montażowego. Następnie ponownie skompilowałem i ponownie wdrożyłem mój kod (prawdopodobnie przesadzam, ale no cóż). Po otwarciu przeglądarki w nowej sesji i ponownym przejściu do adresu URL witryny nadal otrzymuję tę samą wiadomość.

Mogę użyć Eksploratora Windows i sprawdzić, czy na liście znajduje się również wersja Common.dll.

Co jeszcze mogę sprawdzić, aby rozwiązać ten problem? Nie chcę zmieniać odwołania w moim zestawie, aby wskazywała na starszą wersję.

Answer 1

3 pomysły, aby spróbować:

1. Upewnij się, że wszystkie pliki DLL są kompilowane przeciwko tej samej wersji wspólnego.
2. Sprawdź, czy w pliku referencyjnym znajdują się odwołania do projektu, a nie odwołania do plików.
3. Zastosowanie binding redirections w web.config

Answer 2

(oprócz idei Jakub”)

miałem ten błąd, ponieważ "Rebuild" naprawdę nie przebudowa.
Zamknij Visual Studio, naprawdę przejdź i usuń folder bin, a następnie odbuduj, może działać lepiej.

Czasami Visual Studio kłamie na temat referencji, więc sprawdź HintPath w swoich plikach .

Answer 3

Przejdź do pliku referencyjnego i dodaj nowe odniesienie do pliku dll, który jest przyczyną problemu i upewnij się, że wszystkie biblioteki dll są kompilowane przeciwko tej samej wersji. Działa to dla mnie, mam nadzieję, że to działa również dla ciebie.

Answer 4

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 i upewniając się, że odwoływały się do tego samego pliku dll.

Answer 5

Mój zespół właśnie wpadł na ten problem w naszym środowisku kompilacji. Przyczyną problemu była różnica w elemencie <HintPath> pliku .csproj.

Nasz wspólny zespół miał poprawną względną ścieżkę do katalogu zawierającego nasze zespoły referencyjne. Zależny zespół miał ścieżkę od poprzedniej struktury katalogów. Rozwiązanie zostało pomyślnie skompilowane na komputerach deweloperów, ponieważ GAC rozwiązał zależne odniesienie do poprawnej wersji zainstalowanej w C: \ Program Files. Środowisko budowy miało starszą instalację zespołu (nawet jeśli nie powinno było jej brakować), do którego powrócił i tym samym błąd. Aktualizacja <HintPath> w edytorze tekstu rozwiązała problem.

Answer 6

Miałem podobny problem, utworzyłem DLL, tj. A.dll, który odwoływał się do innych bibliotek DLL, tj. B.dll.

Utworzono aplikację C.exe i biblioteki DLL powiązane A.dll i B.dll.

Rozwiązanie - Po usunięciu odwołania do pliku B.dll z c.exe udało mi się naprawić problem.

Mam nadzieję, że to pomoże.

Answer 7

Jedną z możliwych przyczyn jest to, że drugi zespół jest instalowany w GAC, podczas gdy pierwszy zestaw z wyższym numerem wersji jest dodawany do odnośników projektu. Aby to sprawdzić, kliknij dwukrotnie zespół w odsyłaczach do projektu i sprawdź, czy w przeglądarce obiektów znajduje się inny zestaw o tej samej nazwie.

Jeśli tak jest, użyj narzędzia gacutil.exe, aby odinstalować drugi zestaw z GAC. Na przykład, jeśli są 64-bitowe zespoły:

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

Answer 8

Jeśli używasz Nuget warto będzie „Zarządzaj Nuget Pakiety do sporządzania roztworu”, znalezienie pakietu, który jest przyczyną problemów i uderza aktualizację. Powinien wtedy doprowadzić wszystkie pakiety do najnowszej wersji i rozwiązać problem.

Warto zrobić zdjęcie, ponieważ jest to szybkie i łatwe.

Answer 9

Miał podobny problem. Mój problem polegał na tym, że miałem kilka projektów w ramach tego samego rozwiązania, z których każda odwoływała się do konkretnej wersji biblioteki DLL, ale inne wersje. Rozwiązaniem było ustawienie "Specific Version" na false we wszystkich właściwościach wszystkich referencji.

Answer 10

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

Zlokalizowałem referencję i zmieniłem klucz publiczny z tego, do którego się odwołuje, do starszego.

Mam nadzieję, że to pomoże.

Answer 11

W projekcie znaleźć referances System.Web.Mvc sprawdzić wersję.

Po tym prawym przyciskiem myszy referances -> Zespoły i poszukiwania system.web.mvc i konfiguracji go.

Problem powoduje różne wersje tych zespołów .

Edit: Niż wybrać zarządzania pakietami Nuget i zainstalować aktualizacje (jeśli masz wiele projektów zainstalować aktualizacje do nich również.)

Ważna aktualizacja jest Microsoft.AspNet.Mvc i Microsoft.Net.Compilers Nie zapomnij!

Answer 12

folderu kolekcji Handmade DLL
Jeżeli rozwiązanie ma folder śmieci do plików DLL z różnych bibliotek
lib, source, libs, etc.
Możesz napotkać ten problem, jeśli otworzysz swoje rozwiązanie (na czas pierwszy) w Visual Studio. I folder zbiorczy biblioteki dll jest pominięty w jakiś sposób lub brakuje konkretnego pliku DLL.

Program Visual Studio będzie próbował cicho zastąpić odniesienie biblioteki DLL dla czegoś samodzielnie. Jeśli VS się powiedzie, nowe odniesienie będzie trwałe dla twojego lokalnego rozwiązania. Nie dla innych klonów/kas.

tj. 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.OpenXml będzie odwoływać się od nie C:\Program Files (x86)\Open XML SDK\V2.5\lib z folderu solution\..\lib.

szybko Obejście

• sprawdzić i przywrócić Ci DLL zbieranie folderu
• z Solution Explorer zrobić Unload Projekt, następnie Odśwież Projekt.

Prawo Obejście ma przeprowadzić migrację do menedżera pakietów NuGet.

Answer 13

dla SharePoint, upewnij się, że pod folderem głównym nie masz folderu "bin" z plikami DLL, jeśli tak, po prostu go usuń. (i zmień "Kopiuj lokalnie" na false w VS).