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

751

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?

leora
źródło
W moim przypadku stało się tak, ponieważ miałem dwa projekty ładujące tę samą bibliotekę DLL z różnymi wersjami. (mam nadzieję, że to komuś pomoże!)
miguelmpn

Odpowiedzi:

461

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 .

Lars Truijens
źródło
19
ale kiedy patrzę na referencje projektu, wskazuje to na 1.2.0.203 .. nic już nie wskazuje na 1.2.0.200
leora
128
Dokładnie - szuka 1.2.0.203, ale znalazł 1.2.0.200. Dowiedz się, gdzie jest ten plik i zastąp go odpowiednią wersją.
Jon Skeet
18
Zadałem tutaj podobne pytanie i otrzymałem działające rozwiązanie: stackoverflow.com/questions/4187907/…
Michael La Voie
13
Sprawdź wersję referencji, a następnie sprawdź, czy jest ona taka sama w pakietach.config i Web.config
zdarsky.peter
4
Ta wiadomość za każdym razem myli mnie. Wydaje się, że jest napisane wstecz. Spodziewałbym się, że będzie narzekać na wersję, którą załadowałeś, a nie na wersję, którą znalazł. Cieszę się, że nie jestem jedyną, która popełnia błąd!
Greg Woods,
91

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.

Seth Petry-Johnson
źródło
19
Nie zapominaj, że wersja pliku nie jest częścią tożsamości zestawów. Wersja zestawu jest, ale nie musi być taka sama jak wersja pliku!
Lars Truijens,
Jeśli używasz fuslogvw do usług, przeczytaj blogs.msdn.com/b/junfeng/archive/2004/02/14/72912.aspx
Nick
Wyszukiwanie nazwy pliku rozwiązało mój problem. Miałem starą wersję biblioteki dll w folderze Temporary ASP.Net, a InstallShield używał jej zamiast aktualnej wersji! Czyste rozwiązanie, odbuduj, uruchom ponownie komputer nic nie zrobił. Działał dobrze lokalnie i wysadzał się za każdym razem, gdy był wdrażany.
JumpingJezza
Zaraz po zbudowaniu moja strona działa dobrze, ale chwilę później ten problem się pojawia.
Shavais
Zamiast tego zredagowałem tę odpowiedź, by powiedzieć wersję asemblera.
Worthy7
60

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.

Nathan Bedford
źródło
2
+1 Coś podobnego przydarzyło mi się, gdy jedna z moich bibliotek DLL odwołuje się do starszej wersji Caliburn Micro.
Jason Massey
ja też, twoje doświadczenie sprawiło, że popatrzyłem tam, gdzie muszę spojrzeć i naprawiłem swój problem.
Esen
Inną opcją byłoby otwarcie CompanyControlsprojektu, kliknij prawym przyciskiem myszy CompanyClasses.dllodnośnik -> właściwości ->SpecificVersion = false
BlueRaja - Danny Pflughoeft
dzieje się tak bardzo często w aplikacjach Xamarin. Miałem projekt xamarin.forms inny niż projekt xamarin.droid. Właśnie zobaczyłem twój post i rozpoznałem go.
batmaci,
Jeśli CompanyClasses.dll jest podpisany, SpecificVersion = falsesam nie będzie go wycinać. Będziesz potrzebował bindingredirect.
Denise Skidmore
53

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.

Yaniv.H
źródło
1
To zadziałało dla mnie. Zmieniłem „newVersion = 3.3.3” na „newVersion = 3.1.0”
jward01
Najlepiej jednak nie schodzić z trasy ponownego wiązania, jeśli można tego uniknąć. Kiedy ten błąd cię ugryzie, gryzie cię mocno.
BanksySan,
1
Mój problem polegał na tym, że przekierowania wskazywały na nieistniejące zespoły. App.Config przechowywał informacje o zespole z najnowszych pakietów NuGet, które zainstalowałem. Kiedy później obniżyłem te pakiety, NIE oczyściłem tego. Była to biblioteka klasy standardowej .NET, która została trafiona przez projekt testów jednostkowych platformy 4.7.2. Kwestia projektu testu jednostkowego przedstawiona w czasie wykonywania.
D-Sect
@ D-Sect ma rację. Jeśli kontrola źródła wskazuje, że w pliku web.config wprowadzono zmiany (ponieważ grałeś przy użyciu NuGets), rozsądne może być wycofanie tych powiązań. Obniżenie wersji NuGets nie usunie wiążących przekierowań
bkwdesign
45

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

Berbeć
źródło
14
To zazwyczaj jest dla mnie rozwiązanie. Często usuwam bini objrobimy to. Zasadniczo coś, o czym mówiłem, wciąż tam siedzi i próbuje spełnić te same wymagania. Na przykład stara wersja jest czymś, do czego bezpośrednio się odnosiłem, a nowa wersja jest na NuGet.
David Betz
Napotkano ten problem na kilka bibliotek DLL po pobraniu z TFS. To rozwiązanie naprawiło to dla mnie.
Milo
3
Pracował dla mnie. Usunięto folder bin amd obj i rozwiązano problem.
user1619480,
Dzięki, działało również dla mnie, po prostu usuwając folder bin.
The Cookies Dog
Dla mnie wystarczyło usunąć binfolder. Zaskakująco, próbowałem wcześniej czystego rozwiązania i przebudowałem rozwiązanie bez powodzenia. Czasem trochę dziwne.
Lion
36

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. wprowadź opis zdjęcia tutaj

RayLoveless
źródło
8
To ustawienie działa tylko w czasie kompilacji . Po skompilowaniu będzie potrzebować dokładnie tej samej wersji zestawu, z którą ją skompilowałeś. Zobacz stackoverflow.com/questions/24022134/…
Lars Truijens
22

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.

Neal Tibrewala
źródło
Właśnie migrujemy na inny serwer, który miał ten problem, ponieważ przechowujemy kopie zapasowe. Działa po usunięciu kopii zapasowych. Dzięki :)
Jtuck
22

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
codeMonkey
źródło
Pracował również dla mnie. Dzięki
Oleh Udovytskyi
oszczędziłeś mój czas 👌👌
Abdu Imam
4
działa to tylko wtedy, gdy format zarządzania pakietami to packages.config, jeśli używasz csproj 2017 bez pakietów.config, to nie działa :(
ManiVI
1
Umysł oficjalnie zdmuchnięty
BGilman
to niezła sztuczka
hexagod
21

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>
frattaro
źródło
Widziałem to, gdy przynajmniej w przypadku modułu Entity Framework podczas korzystania z NuGet, kliknięcie rozwiązania prawym przyciskiem myszy, przejdź do Zarządzaj pakietami NuGet dla rozwiązania, a następnie Zainstalowane pakiety> Wszystkie, wybierz ten moduł, wybierz Zarządzaj, możesz zwykle odznacz go z twojego projektu. To powinno oczyścić takie rzeczy bez konieczności robienia tego ręcznie - zakładając, że sprzedawca dołożył należytej staranności. Ale dobry połów, ponieważ najwyraźniej czasami tego nie robią, jeśli tak to usunąłeś.
vapcguy
20

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.

Levi Fuller
źródło
3
Dzięki, Levi Fuller. Ta odpowiedź powinna być wyżej; w mojej sytuacji było na miejscu! Dla mnie ten błąd zaczął się, gdy utworzyłem kopię zapasową pliku web.config, a program Visual Studio nadal ładował ten plik konfiguracyjny zamiast rzeczywistej konfiguracji, nawet po usunięciu zduplikowanej kopii. To rozwiązało. Dzięki.
BruceHill,
Dla mnie też działa. Nadal nie jestem pewien, dlaczego to działa :(
KangarooWest
14

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.

Polana Mellor
źródło
2
Działa to dla mnie, gdy zamknąłem Visual Studio, zatrzymałem IIS i usunąłem wszystkie tymczasowe pliki ASP.NET. Uwaga: pliki mogą znajdować się w folderze Framework i Framework64 na komputerze 64-bitowym, a także w folderach .NET 2.0 i 4.0!
Bryan B,
Użyłem funkcji wyszukiwania w menu Start systemu Windows, aby znaleźć wszystkie biblioteki DLL utworzone przez moje rozwiązanie, a następnie usunąłem całą partię, gdziekolwiek zostały znalezione. Mogłem to zrobić bez obaw, ponieważ powinny być tworzone tylko podczas debugowania programu Visual Studio. Ponieważ VS odbuduje brakujące biblioteki DLL i nic poza moim rozwiązaniem nie powinno się do nich odwoływać, była to dla mnie „bezpieczna” operacja.
Zarepheth,
8

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.

Rozpłodnik
źródło
2
W moim przypadku po aktualizacji do nowej wersji DevExpress plik .resx formularza zawierał odniesienia do starej, odinstalowanej wersji biblioteki. Musiałem otworzyć .resx w widoku kodu i albo poprawić wersję do nowej, albo usunąć nieprawidłowe wpisy.
Artemix,
5

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.

Guy Starbuck
źródło
1
Proszę rozwinąć - co to jest „sn -T”? A gdzie dodać token klucza publicznego?
Moritz Zarówno
3
„sn.exe” to narzędzie dostarczane z Visual Studio, to narzędzie wiersza poleceń, które można uruchomić z wiersza polecenia Visual Studio. Wystarczy uruchomić wiersz polecenia programu Visual Studio (z menu Start), przejść do folderu zawierającego zestaw i wpisać „sn -T <zestaw>>, gdzie <zestaw> to pełna nazwa biblioteki dll. Otrzymuje to informacje o „tokenie” zestawu. Gdy już to zrobisz, kiedy robisz późne wiązanie z odbiciem, wprowadź informacje o tokenie w ciągu identyfikatora zestawu (tj. „Assembly = MyAssembly.dll, Token klucza publicznego = <identyfikator tokena>)
Guy Starbuck
2
Dziękuję za tę odpowiedź. Ten błąd pojawiał się podczas odwoływania się do sekcji konfiguracji w moim App.ini. Niedawno podpisałem zestaw, więc PublicKeyToken = null musiał zostać zaktualizowany o nowy (poprawny) token.
Liam,
5

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.

Bijimon
źródło
4

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.

Mike Murphy
źródło
4

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ł.

Oprogramowanie AEON Blue
źródło
4

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

Ben Pretorius
źródło
1
Podobna odpowiedź dla mnie. Update-Package -reinstallponownie instaluje wszystkie pakiety NuGet w tej samej wersji.
Jess,
1
To jest świetne; dzięki za wysłanie. Wypróbowałem te wszystkie inne świetne sugestie, ale to było rozwiązanie, które załatwiło sprawę. Dzięki Bogu za ludzi, którzy nadal chcą opublikować alternatywne rozwiązanie, nawet jeśli jest ich 80
Hambone,
4

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.

cederlof
źródło
Innym sposobem jest kliknięcie „Zarządzaj pakietami NuGet dla rozwiązania ...” i zaktualizuj zarówno projekt testowy, jak i projekt w trakcie testów do tej samej (najnowszej) wersji.
lixonn,
4

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.

Tomasz
źródło
3

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.

Ladislav Mrnka
źródło
3

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

uli78
źródło
3

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

dhiraj1mumbai
źródło
1
Cóż, wiesz, pomogłeś mi nieszczęśliwie, naprawdę dzięki
Ronny Mahlangu
2

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.

Ganesh Londhe
źródło
1

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

Rjain
źródło
1

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.
użytkownik4846550
źródło
1

Oto moja metoda rozwiązania tego problemu.

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

wprowadź opis zdjęcia tutaj

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

wprowadź opis zdjęcia tutaj

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

  1. 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 !

Mike Gledhill
źródło
co jeśli moje pliki csproj nie mają wersji, do której istnieje odniesienie?
John Demetriou,
1

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.

Tomas Kubes
źródło
1

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.

Jaggan_j
źródło
1

Ż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.

Mi1anovic
źródło
0

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”.

dan
źródło