Definicja manifestu zlokalizowanego zespołu nie pasuje do odwołania do zespołu

Próbuję uruchomić niektóre testy jednostkowe w aplikacji Windows Forms w języku C # (Visual Studio 2005) i pojawia się następujący błąd:

System.IO.FileLoadException: Nie można załadować pliku lub zestawu „Utility, Version = 1.2.0.200, Culture = neutralny, PublicKeyToken = 764d581291d764f7” lub jednej z jego zależności. Definicja manifestu zlokalizowanego zespołu nie pasuje do odwołania do zespołu. (Wyjątek od HRESULT: 0x80131040) **

na x.Foo.FooGO ()

na x.Foo.Foo2 (String groupName_) w Foo.cs: linia 123

na x.Foo.UnitTests.FooTests.TestFoo () w FooTests.cs: linia 98 **

System.IO.FileLoadException: Nie można załadować pliku lub zestawu „Utility, Version = 1.2.0.203, Culture = neutralny, PublicKeyToken = 764d581291d764f7” lub jednej z jego zależności. Definicja manifestu zlokalizowanego zespołu nie pasuje do odwołania do zespołu. (Wyjątek od HRESULT: 0x80131040)

Patrzę na moje referencje i mam tylko odniesienia do Utility version 1.2.0.203(drugi jest stary).

Wszelkie sugestie na temat tego, jak dowiedzieć się, co próbuje odwołać się do tej starej wersji tego pliku DLL?

Poza tym nie sądzę, żebym nawet miał ten stary zestaw na dysku twardym. Czy jest jakieś narzędzie do wyszukiwania tego starego zestawu wersji?

Program ładujący zestawu .NET:

• nie można znaleźć 1.2.0.203
• ale znalazłem 1.2.0.200

Ten zestaw nie pasuje do tego, o co prosiono, dlatego pojawia się ten błąd.

Krótko mówiąc, nie można znaleźć zestawu, do którego się odwoływano. Upewnij się, że może znaleźć odpowiedni zespół, umieszczając go w GAC lub na ścieżce aplikacji. Zobacz także https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference .

Możesz zrobić kilka rzeczy, aby rozwiązać ten problem. Najpierw użyj wyszukiwania plików systemu Windows, aby przeszukać dysk twardy w poszukiwaniu zestawu (.dll). Po uzyskaniu listy wyników wykonaj Widok-> Wybierz szczegóły ..., a następnie zaznacz „Wersja pliku”. Spowoduje to wyświetlenie numeru wersji na liście wyników, dzięki czemu można zobaczyć, skąd pochodzi stara wersja.

Ponadto, jak powiedział Lars, sprawdź GAC, aby zobaczyć, która wersja jest tam wymieniona. W tym artykule Microsoft stwierdzono, że zestawy znalezione w GAC nie są kopiowane lokalnie podczas kompilacji, więc może być konieczne usunięcie starej wersji przed wykonaniem przebudowy wszystkich. (Zobacz moją odpowiedź na to pytanie, aby uzyskać informacje na temat tworzenia pliku wsadowego, aby zrobić to za Ciebie)

Jeśli nadal nie możesz dowiedzieć się, skąd pochodzi stara wersja, możesz użyć aplikacji fuslogvw.exe dostarczanej z programem Visual Studio, aby uzyskać więcej informacji o błędach wiązania. Microsoft ma informacji na temat tego narzędzia tutaj . Pamiętaj, że musisz włączyć rejestrowanie, ustawiając HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLogklucz rejestru na 1.

Właśnie natknąłem się na ten problem i odkryłem, że problem był inny niż to, na co wpadli inni.

Miałem dwie biblioteki DLL, do których odwoływał się mój główny projekt: CompanyClasses.dll i CompanyControls.dll. Otrzymałem błąd w czasie wykonywania, mówiąc:

Nie można załadować pliku lub zestawu „CompanyClasses, Wersja = 1.4.1.0, Kultura = neutralny, PublicKeyToken = 045746ba8544160c” lub jednej z jej zależności. Definicja manifestu zlokalizowanego zespołu nie pasuje do odwołania do zespołu

Problem polegał na tym, że nie miałem żadnych plików CompanyClasses.dll w moim systemie o numerze wersji 1.4.1. Brak w GAC, brak w folderach aplikacji ... brak w dowolnym miejscu. Przeszukałem cały dysk twardy. Wszystkie pliki CompanyClasses.dll, które miałem, to 1.4.2.

Odkryłem, że prawdziwym problemem było to, że CompanyControls.dll odwoływał się do wersji 1.4.1 CompanyClasses.dll. Właśnie skompilowałem ponownie CompanyControls.dll (po odwołaniu się do CompanyClasses.dll 1.4.2) i ten błąd zniknął dla mnie.

Poniżej przekierowuje dowolną wersję zestawu do wersji 3.1.0.0. Mamy skrypt, który zawsze aktualizuje to odwołanie w App.config, więc nigdy więcej nie będziemy musieli zajmować się tym problemem.

Poprzez odbicie możesz uzyskać zestaw publicKeyToken i wygenerować ten blok z samego pliku .dll.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

Zauważ, że bez atrybutu przestrzeni nazw XML (xmlns) to nie zadziała.

Jeśli korzystasz z programu Visual Studio, wypróbuj „czyste rozwiązanie”, a następnie odbuduj projekt.

Inne odpowiedzi nie działałyby dla mnie. Jeśli nie zależy ci na wersji i chcesz tylko uruchomić aplikację, kliknij odnośnik prawym przyciskiem myszy i ustaw wartość „konkretna wersja” na false… To zadziałało dla mnie.

Właśnie natknąłem się na ten problem i problem polegał na tym, że miałem starą kopię pliku .dll w katalogu debugowania aplikacji. Możesz także sprawdzić tam (zamiast GAC), aby zobaczyć, czy go widzisz.

Zamierzam teraz wysadzić wszystkich w pamięć. . .

Usuń wszystkie <assemblyBinding>odwołania z pliku .config, a następnie uruchom to polecenie z konsoli Menedżera pakietów NuGet:

Get-Project -All | Add-BindingRedirect

Dodałem pakiet NuGet, aby zdać sobie sprawę, że czarna skrzynka mojej aplikacji odwołuje się do starszej wersji biblioteki.

Usunąłem pakiet i odwołałem się do statycznego pliku DLL starszej wersji, ale plik web.config nigdy nie został zaktualizowany z:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

do tego, co powinno być przywrócone po odinstalowaniu pakietu:

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

W moim przypadku ten błąd wystąpił podczas uruchamiania aplikacji ASP.NET. Rozwiązaniem było:

1. Usuń foldery obji binw folderze projektu

Clean nie działał, przebudowa nie działała, wszystkie referencje były w porządku, ale to nie było pisanie jednej z bibliotek. Po usunięciu tych katalogów wszystko działało idealnie.

W moim przypadku była to stara wersja biblioteki DLL w katalogu C: \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporary ASP.NET Files \. Możesz usunąć lub zastąpić starą wersję albo możesz usunąć i dodać odniesienie do biblioteki DLL w swoim projekcie. Zasadniczo w obu przypadkach zostanie utworzony nowy wskaźnik do tymczasowych plików ASP.NET.

Dla nas problem był spowodowany czymś innym. Plik licencji dla komponentów DevExpress zawierał dwa wiersze, jeden dla starej wersji komponentów, które nie zostały zainstalowane na tym konkretnym komputerze. Usunięcie starszej wersji z pliku licencji rozwiązało problem.

Irytujące jest to, że komunikat o błędzie nie wskazywał, które odniesienie spowodowało problemy.

Ten sam błąd jest zgłaszany, jeśli próbujesz późno powiązać za pomocą odbicia, jeśli zestaw, do którego jesteś przypisany, otrzyma silną nazwę lub zostanie zmieniony token klucza publicznego. Błąd jest taki sam, mimo że w rzeczywistości nie znaleziono żadnego zestawu z określonym tokenem klucza publicznego.

Musisz dodać poprawny token klucza publicznego (można go uzyskać za pomocą sn -T na dll), aby rozwiązać błąd. Mam nadzieję że to pomoże.

Moja była bardzo podobna sytuacja do postu Nathana Bedforda, ale z lekkim zwrotem akcji. Mój projekt również odwoływał się do zmienionej biblioteki dll na dwa sposoby. 1) Bezpośrednio i 2) Pośrednio przez odwołanie do komponentu (biblioteki klas), który sam miał odniesienie do zmienionej biblioteki dll. Teraz mój projekt Visual Studio dla komponentu (2) odwoływał się do poprawnej wersji zmienionej biblioteki DLL. Jednak numer wersji samego komponentu NIE został zmieniony. W rezultacie instalacja nowej wersji projektu nie zastąpiła tego komponentu na komputerze klienckim.

Wynik końcowy: bezpośrednie odwołanie (1) i pośrednie odwołanie (2) wskazywały na różne wersje zmienionej biblioteki DLL na komputerze klienckim. Na mojej maszynie deweloperskiej działało dobrze.

Rozwiązanie: usuń aplikację; Usuń wszystkie biblioteki DLL z folderu aplikacji; Zainstaluj ponownie. Podobnie jak w moim przypadku.

Pozwolę komuś skorzystać z mojej głupoty z powodu ścinania. Mam pewne zależności od całkowicie oddzielnej aplikacji (nazwijmy ją App1). Pliki dll z tej aplikacji 1 są pobierane do mojej nowej aplikacji (App2). Za każdym razem, gdy robię aktualizacje w APP1, muszę utworzyć nowe biblioteki dll i skopiować je do App2. Dobrze. . . Zmęczyło mnie kopiowanie i wklejanie między 2 różnymi wersjami App1, więc po prostu dodałem przedrostek „NEW_” do biblioteki dll.

Dobrze. . . Zgaduję, że proces kompilacji skanuje folder / bin, a gdy coś pasuje niepoprawnie, pojawia się ten sam komunikat o błędzie, jak wspomniano powyżej. Usunąłem moje „nowe” wersje i zbudowałem po prostu dandysa.

Mój problem polegał na kopiowaniu kodu źródłowego na nową maszynę bez przeciągania żadnego z wymienionych zestawów.

Nic, co zrobiłem, nie naprawiło błędu, więc w pośpiechu usunąłem całkowicie katalog BIN. Odbudowałem mój kod źródłowy i odtąd działał.

Chciałbym tylko dodać, że tworzyłem podstawowy projekt ASP.NET MVC 4 i dodałem DotNetOpenAuth.AspNet za pośrednictwem NuGet. Spowodowało to ten sam błąd po odwołaniu się do niezgodnego pliku DLL dla Microsoft.Web.WebPages.OAuth.

Aby to naprawić, zrobiłem Update-Packagei wyczyściłem rozwiązanie do pełnej przebudowy.

To działało dla mnie i jest trochę leniwe, ale czas to pieniądz :-P

Wystąpił ten błąd podczas tworzenia usługi kompilacji serwera Team Foundation Server. Okazało się, że miałem wiele projektów w moim rozwiązaniu, używając różnych wersji tej samej biblioteki dodanych za pomocą NuGet. Usunąłem wszystkie stare wersje za pomocą NuGet i dodałem nową jako odniesienie dla wszystkich.

Team Foundation Server umieszcza wszystkie pliki DLL w jednym katalogu, a jednocześnie może znajdować się tylko jeden plik DLL o określonej nazwie.

Mój app.config zawiera

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

dla npgsql. Jakoś na komputerze użytkownika zaginął mój plik app.exe.config. Nie jestem pewien, czy był to głupi użytkownik, usterka instalatora, czy też usunięty program antywirusowy. Zastąpienie pliku rozwiązało problem.

Właśnie znalazłem inny powód, aby uzyskać ten błąd. Wyczyściłem mój GAC ze wszystkich wersji określonej biblioteki i zbudowałem projekt w oparciu o konkretną wersję wdrożoną wraz z plikiem wykonywalnym. Kiedy uruchamiam projekt, otrzymałem ten wyjątek, szukając nowszej wersji biblioteki.

Powodem były zasady wydawcy . Kiedy odinstalowałem wersje biblioteki z GAC, zapomniałem również odinstalować zestawy zasad wydawcy, więc zamiast używać mojego zestawu wdrożonego lokalnie moduł ładujący zestaw znalazł zasady wydawcy w GAC, które nakazały mu wyszukiwanie nowszej wersji.

Dla mnie konfiguracja pokrycia kodu w pliku „Local.testtesttings” spowodowała „problem”. Zapomniałem zaktualizować pliki, do których się tam odnosiłem.

Usunięcie zawartości folderu bin projektu i przebudowanie rozwiązania rozwiązało mój problem.

wyczyść i odbuduj rozwiązanie może nie zastąpić wszystkich bibliotek DLL z katalogu wyjściowego.

co zasugeruję, spróbuj zmienić nazwę folderu z „bin” na „oldbin” lub „obj” na „oldobj”

a następnie spróbuj ponownie zbudować swoje wyciszenie.

incase, jeśli korzystasz z bibliotek DLL innych firm, musisz je skopiować do nowo utworzonego folderu „bin” lub „obj” po udanej kompilacji.

mam nadzieję, że to zadziała dla ciebie.

Pomocne może być ręczne usunięcie starego zestawu z lokalizacji folderu, a następnie dodanie odwołania do nowych zespołów.

Wystąpił ten sam błąd ... W moim przypadku problem został rozwiązany w następujący sposób:

• Na początku, gdy aplikacja została zainstalowana, ludzie tutaj korzystali z aplikacji Microsoft Enterprise Library 4.1.
• W poprzednim tygodniu mój komputer został sformatowany, a później, kiedy skompilowałem tę aplikację, pojawił się błąd, że brakuje zestawu biblioteki korporacyjnej.
• Następnie zainstalowałem Microsoft Enterprise Library 5.0, który dostałem w Google jako pierwszy wpis wyszukiwania.
• Następnie, gdy skompilowałem aplikację, otrzymałem powyższy błąd, tzn. Definicja manifestu zlokalizowanego zestawu nie pasuje do odwołania do zestawu.
• Po wielu pracach związanych z wyszukiwaniem i analizą odkryłem, że aplikacja odnosi się do wersji 4.1.0.0, a biblioteka DLL w folderze bin ma wersję 5.0.0.0
• Następnie zainstalowałem bibliotekę Microsoft Enterprise Library 4.1.
• Usunięto poprzednie odniesienie (5.0) i dodano odniesienie 4.0.
• Zbudowałem aplikację i voila ... działało.

Oto moja metoda rozwiązania tego problemu.

1. Z komunikatu wyjątku uzyskaj nazwę biblioteki „problem” i „oczekiwany” numer wersji.

2. Znajdź wszystkie kopie tego pliku .dll w swoim rozwiązaniu, kliknij je prawym przyciskiem myszy i sprawdź, która to wersja .dll.

Okej, więc w tym przykładzie moja .dll to zdecydowanie 2.0.5022.0 (więc numer wersji wyjątku jest niepoprawny).

3. Wyszukaj numer wersji pokazany w komunikacie o wyjątku we wszystkich plikach .csproj w swoim rozwiązaniu. Zastąp ten numer wersji faktycznym numerem z biblioteki dll.

W tym przykładzie zastąpiłbym to ...

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... z tym...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

Zadanie wykonane !

W moim przypadku problem dotyczył krzesła i klawiatury :-)

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

Dwa lub więcej różnych zestawów chciało użyć innej wersji biblioteki DotNetOpenAuth, a to nie stanowiłoby problemu. Ponadto na moim komputerze lokalnym plik web.config został automatycznie zaktualizowany przez NuGet:

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

Potem zdałem sobie sprawę, że zapomniałem skopiować / wdrożyć nowy plik web.config na serwerze produkcyjnym. Jeśli masz ręczny sposób wdrażania pliku web.config, sprawdź, czy jest zaktualizowany. Jeśli masz zupełnie inny plik web.config dla serwera produkcyjnego, po użyciu NuGet musisz zsynchronizować te sekcje zależneZłączanie.

Jeśli kiedykolwiek pojawi się błąd, taki jak: „ Definicja manifestu zlokalizowanego zestawu nie pasuje do odwołania do zestawu ” i jeśli dokonałeś aktualizacji poprzez Projekt> Zarządzaj pakietami NuGet i aktualizację w VS , pierwszą rzeczą, którą możesz zrobić, to spróbować zainstalować inną wersję pakiet po sprawdzeniu wersji ze strony Galerii NuGet i uruchomieniu polecenia folowing z konsoli Menedżera pakietów:

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

Chociaż odpowiedź nie jest bezpośrednio związana z danym pakietem i została zadana w drodze powrotnej, jest dość ogólna, wciąż aktualna i mam nadzieję, że komuś pomoże.

Żadne rozwiązanie nie działało dla mnie. Próbowałem czystego rozwiązania projektu, usunąłem bin, pakiet aktualizacji, pakiet starszej wersji i tak dalej ... Po dwóch godzinach załadowałem domyślny App.config z projektu z zestawami i tam zmieniłem złą wersję referencyjną z:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

do:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

Po tym wyczyściłem projekt, zbuduj go ponownie i działało. Bez ostrzeżenia nie ma problemu.

Otrzymałem ten komunikat o błędzie z powodu odwołania się do zestawu o tej samej nazwie co zestaw, który budowałem.

To skompilowało, ale nadpisało przywoływany zestaw z bieżącym zespołem projektów - powodując w ten sposób błąd.

Aby to naprawić, zmieniłem nazwę projektu i właściwości zestawu dostępne poprzez kliknięcie projektu prawym przyciskiem myszy i wybranie „Właściwości”.