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

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.

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.

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.

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.

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

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ę!

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.

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)

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.

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:

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

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 :

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?

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)

4), 5)

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

• 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).

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.

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.

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)

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

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

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

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

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

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.

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

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

Microsoft.Practices.Unity.Interception.dll

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

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

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

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.

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.

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