Nie można załadować pliku lub zestawu ani jednej z jego zależności

238

Mam inny z tych problemów „Nie można załadować pliku lub zestawu lub jednej z jego zależności”.

Informacje dodatkowe: Nie można załadować pliku lub zestawu „Microsoft.Practices.Unity, Version = 1.2.0.0, Culture = neutralny, PublicKeyToken = 31bf3856ad364e35” 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)

Nie mam pojęcia, co jest przyczyną tego problemu ani jak mogę go debugować, aby znaleźć przyczynę.

Przeprowadziłem wyszukiwanie w moich katalogach rozwiązań plików .csproj i wszędzie tam, gdzie mam Unity, mam:

Odniesienia obejmują = „Microsoft.Practices.Unity, Version = 2.0.414.0, Culture = neutralny, PublicKeyToken = 31bf3856ad364e35, ProcessorArchitecture = MSIL”

Nie mogę znaleźć nigdzie odniesienia, które byłoby sprzeczne z 1.2.0.0 w żadnym z moich projektów.

Jakieś pomysły, jak powinienem rozwiązać ten problem?

Byłbym także wdzięczny za wskazówki, jak ogólnie debugować takie problemy.

ronag
źródło
1
Czy któryś z zestawów, do których się odwołujesz, może używać pewnych rzeczy w starej Unitybibliotece?
decyklon
3
Prawdopodobnie ... ale jak mogę znaleźć, które zespoły? Mam wiele projektów w swoim rozwiązaniu i wielu potencjalnych podejrzanych ... brutalna siła prób i błędów wydaje się trochę beznadziejna ...
ronag
3
To nie jest odwołanie do zestawu, odwołujesz się do wersji 2.0. Ale w czasie wykonywania CLR znajduje starszą wersję 1.2. Jeśli nie widzisz tej starej biblioteki DLL w katalogu kompilacji, użyj narzędzia Fuslogvw.exe, aby dowiedzieć się, w jaki sposób CLR znalazł tę starą kopię.
Hans Passant,
2
Spójrz na folder bin projektu i sprawdź, czy dll projektu ma konflikt w nazwie. Po prostu usuń ten, a następnie odbuduj swoje rozwiązanie. To działało dla mnie.
coggicc
11
„lub jedna z jego zależności” jest tą częścią, która naprawdę mnie denerwuje. Jeśli nie można załadować „jednej z jego zależności”, błąd powinien wskazywać, której „jednej z jego zależności” nie można załadować. Obecna forma jest bezużyteczna, może równie dobrze powiedzieć, że nie można załadować czegoś dziwnego
Paul McCarthy

Odpowiedzi:

116
  1. Sprawdź, czy odwołujesz się do zestawu, który z kolei odwołuje się do starej wersji jedności. Na przykład załóżmy, że masz wywoływany zestaw, ServiceLocator.dllktóry wymaga starej wersji zestawu Unity, a teraz, gdy odwołujesz się do niego ServiceLocator, powinieneś dostarczyć mu starą wersję Unity, i to stanowi problem.

  2. Może być folderem wyjściowym, w którym wszystkie projekty budują swoje zespoły, ma starą wersję jedności.

Możesz użyć FusLogVw, aby dowiedzieć się, kto ładuje stare zestawy, po prostu zdefiniuj ścieżkę do dziennika i uruchom swoje rozwiązanie, a następnie zaznacz (w FusLogvw) pierwszą linię, w której ładowany jest zestaw Unity, kliknij go dwukrotnie i zobacz wywołanie montaż i proszę bardzo.

Nour Sabouny
źródło
6
Gdzie jest plik dziennika FuseLogVw
Stiger
1
Aby uniknąć konieczności znajdowania pliku dziennika, możesz określić niestandardową ścieżkę dziennika: Ustawienia, zaznacz pole wyboru Włącz niestandardową ścieżkę dziennika, wprowadź niestandardową ścieżkę dziennika, odśwież.
RedGreenCode
82

Otwórz Menedżera IIS

Wybierz Pule aplikacji

następnie wybierz pulę, której używasz

przejdź do ustawień zaawansowanych (po prawej stronie)

Zmień flagę Włącz 32-bitową aplikację na false na true.

kranthi
źródło
IIS -> wybierz każdą pulę aplikacji -> Ustawienia podstawowe -> sprawdź, czy wybrana jest najnowsza struktura w menu rozwijanym „Wersja .NET Framework”
Martin,
Możesz także kliknąć projekt prawym przyciskiem myszy w VS. i usuń preferowany 32-bitowy znacznik wyboru
eran otzap
Dzięki. Zadziałało. W moim przypadku było to już Prawdą, tylko na próbę. Zrobiłem to False i zadziałało.
meekash55
Kiedy połączyłem projekt z 1 serwera na inny, ta flaga rzeczywiście była znowu Fałszywa, dzięki za rozwiązanie!
Appsum Solutions
69

Dla mnie żadne inne rozwiązanie nie zadziałało (w tym strategia czyszczenia / odbudowy). Znalazłem inne rozwiązanie obejścia, które polega na zamknięciu i ponownym otwarciu programu Visual Studio .

Myślę, że to zmusza Visual Studio do ponownego załadowania rozwiązania i wszystkich projektów, ponownie sprawdzając zależności w tym procesie.

Robotnik
źródło
33
Jeśli nie wierzysz, że to zadziała, przynajmniej spróbuj. Sam nie mogłem w to uwierzyć, dopóki tego nie zrobiłem.
Ben Cull
3
😍😍😍😍😍😍😍😍😍😍😍 Pracował dla mnie
Devidas M. Das
48

Spróbuj wyczyścić foldery debugowania i wydania w swoim rozwiązaniu. Następnie usuń i dodaj ponownie jedność.

Aleksei Anufriev
źródło
3
Przyczyną tego problemu może być wiele rzeczy ... Twoje rozwiązanie rozwiązało moje problemy i może rozwiązać również problemy innych.
Scott Rippey,
1
@ScottRippey To zadziałało dla mnie. Najpierw usunąłem wszystkie pliki .pdb, a następnie ponownie załadowałem projekt i przebudowałem go.
botenvouwer
21

Przy 99% nie można załadować pliku lub zestawu lub jeden z problemów związanych z zależnościami jest spowodowany przez zależności! Proponuję wykonać następujące kroki:

  1. Pobierz Dependency Walker ze strony http://www.dependencywalker.com/

  2. Uruchom Dependency Walker i otwórz bibliotekę DLL (w moim przypadku NativeInterfaces.dll)

  3. Możesz zobaczyć jedną lub więcej dll z błędem na czerwono Błąd otwierania pliku ...

  4. Oznacza to, że tej biblioteki brakuje w twoim systemie; w moim przypadku nazwa dll toMSVCR71.DLL

  5. Możesz pobrać dll brakujących plików z Google i skopiować właściwą ścieżkę (w moim przypadku c:\windows\system32)

  6. W tym momencie musisz zarejestrować nową bibliotekę DLL w GAC (Global Assembly Cache): otwórz terminal DOS i napisz:

    cd \Windows\System32
    regsvr32 /i msvcr71.dll
    
  7. Uruchom ponownie aplikację!

Stefano Lonati
źródło
22
Walker zależności jest świetny, ale kopiowanie losowych bibliotek DLL z Internetu do systemu Windows jest ... mniej świetne. Lepiej jest spróbować znaleźć instalatora, który udostępnia te biblioteki dll.
RJFalconer,
Nie API-MS-WIN-CORE-KERNEL32-PRIVATE-L1-1-1.DLLznaleziono kilku plików ( ) i zaprowadziłem mnie do tego pytania dotyczącego przepełnienia stosu . Zasadniczo należy pamiętać, że niektóre pliki mogą być fałszywie pozytywne, link zawiera więcej szczegółów.
cheriejw
16

Microsoft Enterprise Library (do którego odwołuje się .NetTiers) był naszym problemem, który z kolei odwoływał się do starszej wersji Unity. W celu rozwiązania problemu zastosowaliśmy następujące przekierowanie wiązania w pliku web.config:

<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
            <dependentAssembly>
                <assemblyIdentity name="Microsoft.Practices.Unity.Configuration" publicKeyToken="31bf3856ad364e35" culture="neutral" />
                <bindingRedirect oldVersion="1.0.0.0-2.0.414.0" newVersion="2.1.505.0" />
            </dependentAssembly>
        </assemblyBinding>
    </runtime>
</configuration>

Alternatywnie możesz po prostu zaktualizować bibliotekę Enterprise Library do najnowszej wersji.

Rebecca
źródło
16

Obserwowanie działało dla mnie.

  • Usuń pliki tymczasowe C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files
  • Zamknij VSTS i otwórz ponownie
  • Usuń i dodaj te same biblioteki DLL (Uwaga: dodajesz te same pasujące wersje)
Riddhi M.
źródło
15

Sprawdź plik Web.config / App.config w swoim projekcie. Sprawdź, czy numery wersji są prawidłowe.

<bindingRedirect oldVersion="X.X.X.X-X.X.X.X" newVersion="X.X.X.X" />

To zadziałało dla mnie.

Jaseem Abbas
źródło
2
To zadziałało dla mnie, chociaż był to web.config, a nie app.config
samneric
15

Pomimo opublikowania pierwotnego pytania pięć lat temu problem nadal występuje i jest raczej denerwujący.

Ogólnym rozwiązaniem jest dokładna analiza wszystkich odnośnych zestawów, aby zrozumieć, co się dzieje. Aby uprościć to zadanie, stworzyłem narzędzie (rozszerzenie Visual Studio), które pozwala wybrać zestaw .NET ( plik .dlllub .exeplik), aby uzyskać wykres wszystkich odnośnych zestawów, jednocześnie podkreślając sprzeczne lub brakujące odniesienia.

Narzędzie jest dostępne w Visual Studio Gallery: https://marketplace.visualstudio.com/vsgallery/051172f3-4b30-4bbc-8da6-d55f70402734

Przykład wyniku: wprowadź opis zdjęcia tutaj

marss19
źródło
Nie działa z edycjami społecznościowymi Visual Studio
Draex_
Uważam, że powinien istnieć inny problem niezwiązany z edycją Visual Studio. Przetestowałem rozszerzenie w wersjach społecznościowych VS 2017 i VS 2015. W rzeczywistości został opracowany za pomocą wersji społecznościowej VS 2017.
marss19
Aha. Czy masz zainstalowane jakieś inne rozszerzenia? Ta strona mówi, że DGML nie jest obsługiwany w VS Community: msdn.microsoft.com/en-us/library/hh871439.aspx#VersionSupport
Draex_
1
W wydaniu Community nie ma żadnych narzędzi architektury, ale sam edytor DGML jest dostępny. Możesz go zainstalować, wybierając „Zainstaluj edytor DGML” w „Indywidualnych komponentach” -> „Narzędzia kodu” za pomocą Instalatora Visual Studio -> Zmień
marss19,
11

zrzut ekranuW eksploratorze rozwiązań kliknij prawym przyciskiem myszy projekt (nie rozwiązanie), w zakładce kompilacji wybierz Cel platformy: „Dowolny procesor”.

Engin Aydogdu
źródło
Po sprawdzeniu puli aplikacji „Włącz 32-bitowe aplikacje” ustawiono na False, ale moją platformą docelową było x86. Zmiana na dowolny procesor LUB x64 rozwiązała mój problem.
Keith Ketterer
11

Odpowiedź Juntos jest poprawna, ale należy również wziąć pod uwagę:

Dla unity v2.1.505.2 określone są różne atrybuty AssemblyVersion i AssemblyFileVersion :

wprowadź opis zdjęcia tutaj

AssemblyFileVersion jest używany przez Nuget ale CLR nie dba o niego! CLR będzie używał tylko AssemblyVersion !

Dlatego przekierowania należy zastosować do wersji określonej w atrybucie AssemblyVersion . Dlatego należy zastosować 2.1.505.0

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <assemblyIdentity name="Microsoft.Practices.Unity" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.1.505.0" newVersion="2.1.505.0" />
</dependentAssembly>
</assemblyBinding>

Zobacz także: Jakie są różnice między AssemblyVersion, AssemblyFileVersion i AssemblyInformationalVersion?

Ievgen Naida
źródło
6

Dostałem też ten straszny błąd i znalazłem rozwiązanie tego ...

  1. Kliknij prawym przyciskiem myszy nazwę rozwiązania
  2. Kliknij opcję Wyczyść rozwiązanie
  3. Uruchom ponownie Visual Studio
  4. Idź do projektu Właściwości >> Kompilacja
  5. Zmień konfigurację na wydanie
  6. Rozpocznij debugowanie (F5)

1), 2)

Kliknij prawym przyciskiem myszy nazwę rozwiązania

4), 5)

Zmień konfigurację na wydanie

Mam nadzieję, że to również pomoże.

Roshana Pitigala
źródło
5
  • Idź do: Rozwiązanie -> Pakiet
  • Kliknij kartę Zaawansowane (Znajdź poniżej strony)
  • Dodaj swoją bibliotekę DLL do dodatkowych zestawów (w ten sposób możemy dodać zewnętrzne biblioteki DLL w programie Sharepoint).
Vijay Singh
źródło
7
Nie mam „Rozwiązanie -> Pakiet” w moim projekcie VS2010
Muflix,
5

Nie jestem pewien, czy to może pomóc.

Sprawdź, czy nazwa zestawu i domyślna przestrzeń nazw w polach w twoich zestawach są zgodne. To rozwiązało mój problem, który spowodował ten sam błąd.

Sjaan
źródło
Doskonały! Moja nazwa pliku dll i przestrzeń nazw były różne, skopiowałem przestrzeń nazw i zmieniłem nazwę mojej biblioteki dll.
Anynomous Khan
5

W moim przypadku w folderze bin znajdowała się dll bez odniesienia o nazwie Unity.MVC3, próbowałem wyszukać dowolne odniesienie do tego w Visual Studio bez powodzenia, więc moje rozwiązanie było tak proste, jak usunięcie tej dll z folderu bin.

Totodile
źródło
4

Dzięki Riddhi M. Obserwowanie działało dla mnie.

Usuń pliki tymczasowe C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Tymczasowe pliki ASP.NET Zamknij VSTS i otwórz ponownie Usuń i dodaj te same biblioteki DLL (Uwaga: dodajesz te same pasujące wersje)

Sridhar Kommana
źródło
Spędziłem na tym tyle czasu i nie mogę uwierzyć, że to była odpowiedź. Jest to zwykle dobre rozwiązanie, gdy widzisz jakieś dziwne zachowanie w VS. Dziękuję Ci.
Bonez024
3

Mówisz, że masz wiele projektów w swoim rozwiązaniu ... cóż, zacznij od jednego w górnej części kolejności kompilacji. Zdobądź ten, który zbudujesz, a kiedy go wymyślisz, możesz zastosować tę samą poprawkę do pozostałych.

Szczerze mówiąc, prawdopodobnie wystarczy odświeżyć referencję. Wygląda na to, że albo zaktualizowałeś swoją wersję i nie zaktualizowałeś referencji, albo jest to względny problem ze ścieżką, jeśli trzymasz swoje rozwiązanie pod kontrolą źródła. Po prostu sprawdź swoje założenia i ponownie dodaj referencję.

Joel Martinez
źródło
3

Obserwowanie działało dla mnie.

  • Usuń pliki tymczasowe C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319 \ Temporary ASP.NET Files
    • następnie kliknij prawym przyciskiem myszy Pliki tymczasowe Asp.net> właściwości> zabezpieczenia i daj pełną kontrolę dostępu do IIS i wszystkich użytkowników prowadzących mój projekt
tylko ja
źródło
3

Ten problem przydarzył mi się, gdy jedna z moich zależnych bibliotek kompilowała bibliotekę DLL z „Any CPU”, gdy biblioteka nadrzędna spodziewała się kompilacji „x64”.

Creamstout10
źródło
3

Miałem ten sam problem, który rozwiązałem za pomocą poniższych instrukcji:

  1. otwórz menu narzędzi i wybierz opcję
  2. w opcjach okno przejdź do Projekty i Rozwiązania / Projekty internetowe
  3. czek use the 64bit version of IIS ...

wprowadź opis zdjęcia tutaj

mohammad almasi
źródło
2

Musisz usunąć plik appname.dll z folderu wyjściowego. Oczyszczanie folderów debugowania i wydawania. Odbuduj i skopiuj do wygenerowanego folderu dll.

gucci
źródło
2

I „Ustaw jako projekt startowy” rozładowaną / nieuzasadnioną bibliotekę / projekt.

Następnie wdrożyłem.

Zadziałało!

Myślę, że nie można znaleźć .dll, ponieważ początkowo nie było go w zestawie.

nirav
źródło
2

Inna możliwa przyczyna: upewnij się, że przypadkowo nie nadałeś obu projektom tej samej nazwy zestawu we właściwościach projektu.

nathanchere
źródło
Zajęło mi to kilka godzin, aby wymyślić ... Przypadkowo nazwałem mój projekt testu jednostkowego taką samą nazwą jak projekt główny, więc dll projektu testu jednostkowego musiał nadpisywać dll projektu
Iannazzi
2

Moim rozwiązaniem dla .NET 4.0 przy użyciu Enterprise Library 5 było dodanie odwołania do:

Microsoft.Practices.Unity.Interception.dll

MacGyver
źródło
2

Uważaj na sprzeczne odniesienia. Nawet po wyczyszczeniu i odbudowaniu sprzeczne odwołania nadal będą powodować problemy. Mój problem dotyczył AForge i Accord. Usunąłem oba odniesienia i ponownie dodałem odniesienia, wybierając ponownie określone odniesienie (szczególne w moim przypadku, tylko Accord).

użytkownik3791372
źródło
2

Dla mnie przebudowanie gry Unity bez Unity C # Proects Checkmark zadziałało.

Praful Rudra
źródło
2

W moim przypadku żadna z proponowanych odpowiedzi nie zadziałała.

Oto, co zadziałało dla mnie:

  1. Usuń odniesienie
  2. Zmień nazwę biblioteki DLL
  3. Zaimportuj referencję ponownie

Drugi krok był najwyraźniej ważny, ponieważ bez niego nie działał.

Nicolas Raoul
źródło
2

Spróbuj sprawdzić, czy właściwość „Kopiuj do lokalnego” dla odwołania jest ustawiona na wartość true, a konkretna wersja jest ustawiona na wartość true. Dotyczy to aplikacji w Visual Studio.

Srinivas Somasundaram
źródło
2

Miałem to dzisiaj, aw moim przypadku problem był bardzo dziwny:

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0" newVersion="3.1.0.0" />
  </dependentAssembly>0.

Zwróć uwagę na zbłąkane znaki na końcu XML - w jakiś sposób zostały one przeniesione z numeru wersji na koniec tego bloku XML!

  <dependentAssembly>
    <assemblyIdentity name="Microsoft.Owin.Host.SystemWeb" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.1.0.0" newVersion="3.1.0.0" />
  </dependentAssembly>

Zmieniono na powyższe i voila! Wszystko znów działało.

garryp
źródło
1

jeśli pojawia się ten komunikat o błędzie, otwierając aplikację na Windows XP, oznacza to, że najpierw zainstalowałeś tę aplikację, ponieważ nie działa ona bez Net Framework 4 i dodatku Service Pack 3. zainstalowałeś oba i znowu pojawia się ten błąd, więc powinieneś ponownie zainstalować tę aplikację, ale najpierw odinstaluj z dodawania i usuwania

jeśli to nie zadziała, nie obrażaj mnie. Jestem również młodszy

basit durrani
źródło