.Net wybiera nieprawidłową wersję zestawu, do którego się odwołuje

Właśnie skopiowałem istniejący projekt na zupełnie nową maszynę, aby rozpocząć na nim programowanie, i napotkałem problem z wersją jednego z moich zestawów, do których się odwołuję (jak to się dzieje, telerik DLL).

Projekt pierwotnie odwoływał się do starszej wersji zestawu (nazwijmy go v1.0.0.0). Mój nowy komputer ma zainstalowaną najnowszą wersję zestawu, więc pomyślałem, że go zaktualizowałem (nazwijmy nową wersję v2.0.0.0).

Oto problem: jeśli skopiuję starą bibliotekę dll v1.0.0.0 do folderu projektu i dodam ją jako odniesienie, witryna internetowa zostanie uruchomiona bez problemu. Jeśli usunę to odniesienie (a także usunę starą bibliotekę DLL z mojego systemu) i dodam nową wersję (v2.0.0.0), na stronie pojawi się następujący wyjątek:

Nie można załadować pliku lub zestawu „XXXXXX, wersja = 1.0.0.0, Culture = neutral, PublicKeyToken = 121fae78165ba3d4” lub jednej z jego zależności. Definicja manifestu zlokalizowanego zestawu nie jest zgodna z odwołaniem do zestawu. (Wyjątek od HRESULT: 0x80131040)

Oczywiście kod szuka nieaktualnej wersji i nie może jej znaleźć. Ale dlaczego?

Wyszukałem folder rozwiązania dla tego numeru wersji i nie mogłem znaleźć ani jednego odwołania. Dokładnie sprawdziłem tekst pliku .csproj i stwierdziłem, że wersja poprawnie pokazuje najnowszą wersję, a HintPath poprawnie pokazuje ścieżkę do nowej biblioteki DLL. Ponadto, ponieważ nie zainstalowałem starej biblioteki DLL w systemie, nie pojawia się ona w moim GAC (chociaż wersja 2.0.0.0 robi, zgodnie z oczekiwaniami).

Następnie włączyłem przeglądarkę dziennika fuzji, aby spróbować dowiedzieć się, dlaczego szuka tej starej wersji, ale bez powodzenia:

Assembly Load Trace: The following information can be helpful to determine why the assembly 'XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4' could not be loaded.


=== Pre-bind state information ===
LOG: User = MyComp\me
LOG: DisplayName = XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
 (Fully-specified)
LOG: Appbase = file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/
LOG: Initial PrivatePath = d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\bin
Calling assembly : WebApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX/XXXXXX.DLL.
LOG: Attempting download of new URL file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/bin/XXXXXX.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

Mówi się tylko o tym, że zaczyna się od szukania tego starego zestawu. Próbowałem znaleźć rozwiązanie online i widziałem to podobne pytanie SO , ale wydaje się, że jest to dokładne przeciwieństwo mojego problemu. Program tego pytającego znajdował niewłaściwą bibliotekę DLL zamiast przywoływanej. Natomiast mój problem polega na tym, że program w tajemniczy sposób szuka niewłaściwej biblioteki DLL i nie może jej znaleźć, gdy właściwą można znaleźć lokalnie w folderze bin i GAC.

Dlaczego szukam starej wersji? Gdzie jeszcze mogę szukać, aby znaleźć to złe odniesienie?

Domyślam się, że inny zestaw, którego używasz, odwołuje się do starej biblioteki dll. Czy znasz wszystkie inne używane odniesienia projektu i czy którekolwiek z nich ma odniesienie do bibliotek DLL Telerik?

Czy możesz umieścić takie przekierowanie w swoim pliku web.config?

<dependentAssembly>
 <assemblyIdentity name="Telerik" publicKeyToken="121fae78165ba3d4"/>
 <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

Jestem z Chrisem Conwayem w tej sprawie (głosowałem za nim). Problem polega na tym, że odwołujesz się do jednego z zestawów telerik w projekcie, który odwołuje się do innego, którego nie ma.

Po pierwsze: nie instalowałbym żadnych zespołów dostawcy (tj: telerika) w GAC. Materiały Telerika są i tak skompilowane do zaledwie dwóch zespołów (telerik.web.design i telerik.web.ui). Wystarczy wdrożyć je za pomocą aplikacji.

Po drugie, w każdym z Twoich plików .proj (np. .Csproj) będzie znajdował się znak <reference include..>wskazujący na plik Telerik.Web.UI. Zwykle zawiera numer wersji. Upewnij się, że zestaw umieszczony w folderze bin pasuje do tej wersji.

Po trzecie, upewnij się, że WSZYSTKIE Twoje projekty korzystają z najnowszego zestawu. Upewnij się również, że pobierają zestaw ze ścieżki lokalnej zamiast z GAC. (Naprawdę nie podoba mi się GAC. To spowodowało niekończące się problemy w niektórych projektach, nad którymi byłem). Zwykle mamy folder „Assemblies”, którego wszystkie projekty używają do odwołań do zewnętrznych zestawów.

Po czwarte, Visual Studio automatycznie przeszukuje GAC za każdym razem, gdy projekt witryny sieci Web jest ładowany i przekierowuje lokalizacje zestawu, jeśli znajdzie coś w GAC. Nie pamiętam, czy kiedykolwiek robi to w przypadku projektów aplikacji internetowych, ale od dawna nie miałem z nimi problemu. Może to powodować podobne problemy podczas wdrażania.

Po piąte, możesz ponownie powiązać numery wersji dla zestawów w pliku web.config. W tej runtime/assemblybindingsekcji możesz użyć czegoś podobnego do następującego, które przenosi każdy zespół telerik wdrożony w 2008 roku do przodu i wskazuje na bardzo konkretną wersję:

  <dependentAssembly>
    <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
    <bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0" newVersion="2010.02.0713.35" />
  </dependentAssembly>

Wypróbowałem większość odpowiedzi, ale nadal nie mogłem go uruchomić. To zadziałało dla mnie:

kliknij prawym przyciskiem myszy odniesienie -> właściwości -> zmień „Określoną wersję” na fałsz.

Mam nadzieję że to pomoże.

Próbować:

• czyszczenie tymczasowych plików projektu
• czyszczenie plików build i obj
• czyszczenie starych wersji zainstalowanych o godz C:\Users\USERNAME\.nuget\packages\

To zadziałało dla mnie.

1. Przejdź do C: \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG
2. Znajdź plik machine.config
3. otwórz w notatniku
4. znajdź dll konfliktu
5. Usuń to i zapisz.

zestawy kompilacji

addassembly = dllName, Version = 1.0.0000.0000 Culture = neutral, PublicKeyToken = "QWEWQERWETERY"

kompilacja zespołów

pracuje dla mnie.

To nie jest jasna odpowiedź, dlaczego, ale mieliśmy ten problem, oto nasze okoliczności i co go rozwiązało:

Dev 1:

Rozwiązanie zawiera projekt A odwołujący się do pakietu NuGet i projekt MVC odwołujący się do projektu A. Włączone przywracanie pakietu NuGet, a następnie zaktualizowano pakiet NuGet. Wystąpił błąd czasu wykonywania informujący, że nie można znaleźć biblioteki NuGet - ale błąd polega na tym, że szuka starszej, niezaktualizowanej wersji. Rozwiązanie (i to jest śmieszne): Ustaw punkt przerwania w pierwszym wierszu kodu w projekcie MVC, który wywołuje projekt A. Wejdź za pomocą klawisza F11. Rozwiązany - nigdy więcej nie miałem problemu.

Dev 2:

To samo rozwiązanie i projekty, ale magiczny punkt przerwania i krok w rozwiązaniu nie działają. Wszędzie szukałem przekierowań wersji lub innych złych odniesień do tego pakietu Nuget, usunięto pakiet i ponownie go zainstalowałem, wyczyściłem bin, obj, Asp.Net Temp, nic nie rozwiązało. Wreszcie zmieniono nazwę projektu A, uruchomiono projekt MVC - naprawiono. Zmienił nazwę z powrotem na pierwotną nazwę, pozostał naprawiony.

Nie mam żadnego wyjaśnienia, dlaczego to zadziałało, ale wyrwało nas z poważnej sytuacji.

Czy masz jakieś inne projekty w tym rozwiązaniu? (Może być inny projekt odwoływał się do starej wersji) Zwykle w VS zależność dll obejmuje wszystkie projekty w rozwiązaniu.

Mój problem polegał na tym, że stare zestawy znajdowały się w folderze _bin_deployableAssemblies w aplikacji sieci Web. Oznaczało to, że stare zestawy nadpisywały zestawy GAC podczas budowania projektu.

Na wypadek, gdyby ktoś inny oszczędził 3 godziny ... moja sprawa była trochę inna. W moim kodzie użyto DevExpress 11.1 11.1.4.0. Miałem do tego prawidłowe odniesienie w moim kodzie. Ale profiler pamięci .net zainstalował DevExpress w wersji 11.1 w wersji 11.1.12.0 w GAC. W rzeczywistości to nie komponenty, do których się odwoływałem, ale te, do których odwoływały się wewnętrznie, zawiodły. Mimo prób, GAC jest zawsze sprawdzany jako pierwszy. Skompilował się i działał dobrze, ale nie mogłem wyświetlić projektanta formularzy wygrywających, a ślad stosu w ogóle nie pomógł. W końcu odinstalowano profiler pamięci .net i wszystko zostało przywrócone.

Miałem podobny problem i musiałem usunąć wszystko z folderów bin i obj i odbudować, aby ominąć mój problem. Mam nadzieję że to pomoże.

Jeśli ten problem występuje podczas testowania i / lub debugowania aplikacji w środowisku Visual Studio (serwer deweloperski ASP.NET), konieczne jest usunięcie wszystkich plików tymczasowych z folderu deweloperskiej witryny sieci Web. Aby dowiedzieć się, gdzie znajduje się ten folder, poszukaj ikony ASP.NET Development Server na ikonie zasobnika systemu Windows (powinna mieć tytuł podobny do tego: ASP.NET Development Server - Port ####), kliknij prawym przyciskiem myszy ikonę i wybierz Pokaż Detale; W związku z tym, w polu Ścieżka fizyczna dowiesz się, jaki jest folder tymczasowy, wszystkie elementy powinny zostać usunięte, aby rozwiązać problem. Zbuduj i uruchom ponownie witrynę, a problem powinien zostać rozwiązany (ponownie rozwiązany dla środowiska programistycznego).

Miałem ten sam problem z różnymi zestawami odwołującymi się do różnych wersji Newtonsoft.json. Rozwiązaniem, które działało dla mnie, było uruchomienie pakietu aktualizacji z konsoli Menedżera pakietów Nuget.

Ten błąd był nieco mylący - ładowałem niektóre biblioteki DLL, które wymagały określenia architektury x64. W .csprojpliku:

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release-ABC|AnyCPU'">
    <OutputPath>bin\Release-ABC</OutputPath>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

Brak PlatformTargetspowodował ten błąd.

Dostawałem:

Nie można załadować pliku lub zestawu „XXX-new-3.3.0.0” lub jednej z jego zależności. Definicja manifestu zlokalizowanego zestawu nie jest zgodna z odwołaniem do zestawu. (Wyjątek od HRESULT: 0x80131040)

To dlatego, że zmieniłem nazwę zespołu z XXX.dllna XXX-new-3.3.0.0.dll. Przywrócenie nazwy z powrotem do oryginalnej naprawiło błąd.

To prawie tak, jakbyś musiał wyczyścić komputer, aby pozbyć się starej biblioteki dll. Wypróbowałem już wszystko powyżej, a następnie wykonałem dodatkowy krok polegający na usunięciu każdego wystąpienia pliku .DLL, który znajdował się na moim komputerze, i usunięciu każdego odniesienia z aplikacji. Jednak nadal kompiluje się dobrze, a po uruchomieniu odwołuje się do funkcji dll. Zaczynam się zastanawiać, czy gdzieś odwołuje się do niego z dysku sieciowego.

Otrzymałem ten sam komunikat podczas przełączania między dwiema wersjami aplikacji, które odwoływały się do różnych wersji tej samej biblioteki DLL. Chociaż testowałem w różnych folderach, przypadkowo skopiowałem nowszą wersję na starszą wersję.

Dlatego pierwszą rzeczą do sprawdzenia jest wersja biblioteki DLL, do której istnieje odwołanie w folderze aplikacji. W razie czego.

Może to pomaga, a może nie. Wyczyściłem wersje debugowania i wydania, a następnie zmieniłem nazwę folderu OBJ. To w końcu mnie dostało. Poprzednie kroki polegały w zasadzie na usuwaniu odniesień z projektu i dodawaniu ich z powrotem we właściwościach projektu.

W programie My Visual Studio 2015 upewniłem się, że lista ścieżek referencyjnych programu Visual Studio Project jest pusta:

Oto, co zadziałało dla mnie:

I był przy użyciu Microsoft.IdentityModel.Clients.ActiveDirectorywersji 3.19 w projekcie biblioteki klasy, ale miał tylko wersja 2.22 zainstalowane w rzeczywistym projekcie ASP.NET Web Application. Aktualizacja do wersji 3.19 w projekcie aplikacji sieci Web pominęła błąd.

W moim przypadku miałem 3 projekty, 1 projekt główny i 2 projekty podrzędne, do których odnosi się projekt główny. Więc zaktualizowałem projekt główny, pomijając projekt podrzędny. Tam był konflikt. Po zaktualizowaniu całego projektu wszystko działało dobrze.

W VS2017 wypróbowałem wszystkie powyższe rozwiązania, ale nic nie działa. Używamy narzędzi Azure Devops do przechowywania wersji.

1. Z eksploratora zespołów> Eksplorator kontroli źródła

2. Wybierz projekt, który doprowadza Cię do szału przez długi czas

3. Kliknij prawym przyciskiem myszy gałąź lub rozwiązanie> Zaawansowane> pobierz określoną wersję

4. Następnie upewnij się, że zaznaczyłeś pole wyboru nadpisywania plików, jak na zrzucie ekranu

W moim przypadku przypadkowo wybrałem niewłaściwą wersję pakietu Telerik z nuget, który następnie zastąpił każdy pakiet, do którego się odwołałem, niepoprawną wersją. Następnie wstawił przekierowanie wiążące do niewłaściwej wersji, więc nawet po zastąpieniu wszystkiego poprawną wersją nadal szukał niewłaściwej wersji.