Komunikat o błędzie „Nie można załadować jednego lub więcej żądanych typów. Pobierz właściwość LoaderExceptions, aby uzyskać więcej informacji. ”

Opracowałem aplikację przy użyciu Entity Framework , SQL Server 2000, Visual Studio 2008 i Enterprise Library.

Działa absolutnie dobrze lokalnie, ale kiedy wdrażam projekt w naszym środowisku testowym, pojawia się następujący błąd:

Nie można załadować jednego lub więcej żądanych typów. Pobierz właściwość LoaderExceptions, aby uzyskać więcej informacji

Śledzenie stosu: w System.Reflection.Module._GetTypesInternal (StackCrawlMark & ​​stackMark)

w System.Reflection.Assembly.GetTypes ()

w System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly (kontekst ładowania kontekstu)

w System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache (kontekst ładowania kontekstu)

at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache (zestaw montażowy, wartość logiczna loadReferencedAssemblies, słownik 2 knownAssemblies, Dictionary2 i typyInLoading, List`1 i błędy)

at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache (ObjectItemCollection objectItemCollection, Zespół złożenia, Boolean loadReferencedAssemblies)

at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType (typ typu)

at System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType (typ typu, wywołanie zestawuAssembly)

w System.Data.Objects.ObjectContext.CreateQuery [T] (String queryString, ObjectParameter [] parametry)

Entity Framework wydaje się mieć problem, jakiś pomysł, jak to naprawić?

Rozwiązałem ten problem, ustawiając atrybut Kopiuj lokalnie w odniesieniach do mojego projektu na true.

Ten błąd nie ma prawdziwej magicznej odpowiedzi na pocisk. Kluczem jest posiadanie wszystkich informacji, aby zrozumieć problem. Najprawdopodobniej w zespole ładowanym dynamicznie brakuje zestawu referencyjnego. Zestaw ten musi znajdować się w katalogu bin Twojej aplikacji.

Użyj tego kodu, aby ustalić, czego brakuje.

using System.IO;
using System.Reflection;
using System.Text;

try
{
    //The code that causes the error goes here.
}
catch (ReflectionTypeLoadException ex)
{
    StringBuilder sb = new StringBuilder();
    foreach (Exception exSub in ex.LoaderExceptions)
    {
        sb.AppendLine(exSub.Message);
        FileNotFoundException exFileNotFound = exSub as FileNotFoundException;
        if (exFileNotFound != null)
        {                
            if(!string.IsNullOrEmpty(exFileNotFound.FusionLog))
            {
                sb.AppendLine("Fusion Log:");
                sb.AppendLine(exFileNotFound.FusionLog);
            }
        }
        sb.AppendLine();
    }
    string errorMessage = sb.ToString();
    //Display or log the error based on your application.
}

Jednym z rozwiązań, które działało dla mnie, było usunięcie folderów bin / i obj / i przebudowanie rozwiązania.

Dwa możliwe rozwiązania:

1. Kompilujesz w trybie Release, ale wdrażasz starszą skompilowaną wersję z katalogu debugowania (lub odwrotnie).
2. Nie masz zainstalowanej poprawnej wersji .NET Framework w środowisku testowym.

Jak już wspomniano wcześniej, zwykle nie ma tam zgromadzenia.

Aby dokładnie wiedzieć, którego zestawu brakuje, podłącz debugger, ustaw punkt przerwania, a gdy zobaczysz obiekt wyjątku, przejdź do właściwości „LoaderExceptions”. Brakujący zestaw powinien tam być.

Mam nadzieję, że to pomoże!

Rozwiązaniem było sprawdzenie LoaderException: W moim przypadku brakowało niektórych plików DLL.

Upewnij się, że zezwalasz na aplikacje 32-bitowe w IIS, jeśli zostały wdrożone w IIS. Możesz to zdefiniować w ustawieniach swojej aktualnej puli aplikacji.

Ten błąd wystąpił w programie ASP.NET 4 + SQL Server 2008 R2 + Entity Framework 4.

Działa dobrze na moim komputerze programistycznym (Windows Vista 64-bit). Następnie po wdrożeniu na serwerze ( Windows Server 2008 R2 z dodatkiem SP1) działałoby do momentu przekroczenia limitu czasu sesji. Wdrożylibyśmy aplikację i wszystko wyglądało dobrze, a następnie pozostawiliśmy na ponad 20 minutowy limit czasu sesji, a następnie ten błąd zostałby zgłoszony.

Aby go rozwiązać, użyłem tego kodu na blogu Kena Coxa aby pobrać właściwość LoaderExceptions.

W mojej sytuacji brakowało biblioteki DLL Microsoft.ReportViewer.ProcessingObjectModel(wersja 10). Ta biblioteka DLL musi być zainstalowana w GAC komputera, na którym działa aplikacja. Można go znaleźć w pakiecie redystrybucyjnym Microsoft Report Viewer 2010 dostępnym w witrynie pobierania firmy Microsoft.

Początkowo próbowałem przeglądarki dziennika Fusion, ale to nie pomogło, więc skończyłem z WinDbg z rozszerzeniem SOS.

! dumpheap -stat -type Wyjątek / D

Następnie zbadałem wyjątki FileNotFoundExceptions. Komunikat w wyjątku zawierał nazwę biblioteki DLL, która się nie ładowała.

Uwaga: / D daje wyniki hiperłącza, więc kliknij link w podsumowaniu dla FileNotFoundException. Spowoduje to wyświetlenie listy wyjątków. Następnie kliknij link jednego z wyjątków. To zrzuci te wyjątki. Następnie powinieneś być w stanie po prostu kliknąć link do wiadomości w obiekcie wyjątku, a zobaczysz tekst.

Jeśli używasz EntityDataSource w swoim projekcie, rozwiązaniem jest poprawka: „Nie można załadować jednego lub więcej żądanych typów” Błędy . Powinieneś ustawić ContextTypeName = "ProjectNameNameSpace.EntityContainerName" '

To rozwiązało moje problemy ...

Moje wystąpienie tego problemu zakończyło się brakującym odniesieniem. Do zestawu przywołano w app.config, ale nie miał on odniesienia w projekcie.

Jeśli używasz Entity Framework , spróbuj skopiować następujące odwołania lokalnie.

• System.Data.Entity
• System.Web.Entity

Zmień właściwość „Kopiuj lokalnie” na „Prawda” dla tych odniesień i opublikuj.

Kolejne rozwiązanie, aby dowiedzieć się, dlaczego dokładnie nic nie działa (z Microsoft Connect):

1. Dodaj ten kod do projektu:

   foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
   {
       asm.GetTypes();
   }

2. Wyłącz generowanie zestawów serializacji.

3. Kompiluj i wykonuj.

Miałem .NET 4.0, ASP.NET MVC 2.0, Entity Framework 4.0 opracowaną w Visual Studio 2010. Miałem ten sam problem, że działał na jednym Windows Server 2008 R2, ale nie na innym serwerze Windows Server 2008 R2, mimo że wersje .NET i ASP.NET MVC były takie same, zgłasza ten sam błąd co twój.

Poszedłem zgodnie z sugestią miko, więc zainstalowałem Windows SDK 7.1 (x64) na uszkodzonym serwerze, aby móc uruchomić! Dumpheap.

Okazuje się, że zainstalowanie zestawu Windows SDK 7.1 (x64) rozwiązało problem. Jakakolwiek zależność była brakująca, musiała zostać zawarta w zestawie SDK. Można go pobrać z zestawu Microsoft Windows SDK dla systemu Windows 7 i .NET Framework 4 .

Dodanie do tego mojego konkretnego problemu / rozwiązania, ponieważ jest to pierwszy wynik tego komunikatu o błędzie. W moim przypadku wystąpił błąd, gdy wdrożyłem drugą aplikację w folderze mojej pierwszej aplikacji w IIS . Oba definiowały parametry połączenia o tej samej nazwie, co spowodowało konflikt aplikacji podrzędnej i generowało ten (dla mnie) nieoczywisty komunikat o błędzie. Zostało to rozwiązane poprzez dodanie:

<clear/>

w bloku ciągu połączenia potomnej aplikacji internetowej, który uniemożliwił jej dziedziczenie ciągów połączeń plików web.config znajdujących się wyżej w hierarchii, więc wygląda to tak:

<connectionStrings>
  <clear/>
  <add name="DbContext" connectionString="MySERVER" providerName="System.Data.SqlClient" />
</connectionStrings>

Referencyjne pytanie przepełnienia stosu, które pomogło, gdy ustaliłem, co się dzieje, to czy aplikacja potomna odziedziczy po nadrzędnym pliku web.config? .

To zadziałało dla mnie. Dodaj go w pliku web.config

<system.web>
  <trust level="Full" />

Mój problem został rozwiązany po usunięciu zbędnych plików zespołu z binfolderu.

W przypadku, gdy żadna z pozostałych odpowiedzi nie pomoże:

Kiedy miałem ten problem, okazało się, że moja usługa Windows została zbudowana na platformę x64 i nieumyślnie uruchomiłem 32-bitową wersję InstallUtil.exe. Upewnij się więc, że używasz odpowiedniej wersji InstallUtil dla platformy, dla której zbudowałeś.

Inne sugestie są dobre. W moim przypadku problem polegał na tym, że pole programisty było 64-bitową maszyną używającą lokalizacji x86 różnych interfejsów API, w tym Silverlight .

Zmieniając platformę docelową w celu dopasowania do 32-bitowego serwera, na którym wdrażana była aplikacja internetowa, usunięto większość błędów związanych z niemożnością załadowania jednego lub więcej żądanych typów.

Zmieniłem właściwość konkretnej wersji Refrences na false i to pomogło.

Ten sam komunikat o błędzie został zgłoszony podczas kompilowania pakietu Visual Studio (VSPackage). Całe rozwiązanie się kompiluje, a błąd jest generowany, gdy pakiet jest tworzony przez CreatePkgDef. To powiedziawszy, jasne jest, że nie mogę złapać wyjątków LoaderExceptions ponieważ to nie moja aplikacja je wyrzuca, ale własne narzędzie Microsoft. (Chociaż jestem odpowiedzialny za zamieszanie w CreatePkgDef.)

W moim przypadku główną przyczyną było to, że moje rozwiązanie tworzy plik MyDll.dll, który został już zarejestrowany w GAC (i są różne), więc CreatePgkDef pomylił, którego użyć, i postanowił po prostu zgłosić błąd, który nie jest naprawdę pomocny. MyDll.dll w GAC został zarejestrowany przez instalatora tego samego produktu (oczywiście wcześniejszej wersji, z / nieznacznie / inną zawartością).

Jak to naprawić

1. Preferowany sposób: upewnij się, że używasz poprawnej wersji MyDll.dll
   2. Podczas kompilowania projektu upewnij się, że używasz innego numeru wersji niż poprzednia wersja znajdująca się w GAC. Upewnij się, że następujące atrybuty są poprawne:
      • [zespół: AssemblyVersion („1.0.0.1”)] // Zakładając, że stary plik DLL ma wersję 1.0.0.0
      • [assembly: AssemblyFileVersion („1.0.0.1”)] // Zakładając, że stary plik DLL został zaktualizowany do wersji 1.0.0.0
   3. W razie potrzeby określ pełną nazwę zestawu (na przykład „MyDll.dll, wersja = 1.0.0.1, Kultura = neutralna, PublicKeyToken = 1234567890abcdef”), gdy odwołujesz się do niej w innych projektach.
2. Jeśli powyższe nie powiedzie się: możesz odinstalować starą MyDll.dll z GAC
   1. Jak odinstalować zestaw z GAC
   2. Odinstaluj aplikację zawierającą MyDll.dll

Zmiana zestawu Wersja była dla mnie wystarczająca. :)

Mam nadzieję, że to było pomocne.

Miałem ten sam problem (ale mój lokalny), gdy próbowałem dodać migrację Entity Framework za pomocą konsoli Menedżera pakietów.

Rozwiązałem to, tworząc aplikację konsolową, w której Main () miał następujący kod:

 var dbConfig = new Configuration();
 var dbMigrator = new DbMigrator(dbConfig);
 dbMigrator.Update();

Upewnij się, że klasa Configuration jest konfiguracją migracji Twojego nieudanego projektu. Będziesz potrzebował System.Data.Entity.Migrations, aby korzystać z DbMigrator.

Ustaw punkt przerwania w aplikacji i uruchom go. Wyjątek powinien zostać przechwycony przez Visual Studio (chyba że masz ustawiony ten typ wyjątku, aby nie przerywać sesji debugowania) i powinieneś być w stanie znaleźć informacje, których szukasz.

Brakującym odniesieniem w moim przypadku był EFProviderWrapperToolkit.

Ten problem wystąpił, gdy zainstalowałem pakiet NuGet w jednym z projektów i zapomniałem zaktualizować drugi projekt.

Rozwiązałem to, tworząc oba projekty z tym samym zestawem referencyjnym.

Stało się to także dla mnie. Rozwiązałem problem w następujący sposób: Kliknij prawym przyciskiem myszy Rozwiązanie, Zarządzaj pakietami NuGet dla rozwiązania ... Skonsoliduj pakiety i zaktualizuj pakiety, aby były w tej samej wersji.

Ustaw 32-bitowy tryb IIS na true, tryb debugowania na true w pliku konfiguracyjnym, usunięcie tempkatalogu i zresetowanie IIS tymczasowo rozwiązuje problem i powraca po pewnym czasie.

Sprawdź, czy każdy projekt jest poprawnie skonfigurowany w programie Configuration Manager .

Podobnie jak przyczyna tego problemu dla Williama Edmondsona, zmieniłem ustawienie Menedżera konfiguracji z „Debuguj” „Dowolny procesor” na „Debuguj” „.NET”. Problem polegał na tym, że wersja „.NET” NIE została skonfigurowana do budowania WSZYSTKICH projektów, więc niektóre z moich bibliotek DLL były nieaktualne (podczas gdy inne były aktualne). Powodowało to wiele problemów z uruchomieniem aplikacji.

Tymczasową poprawką było zrobienie sugestii Kenny'ego Eliassona, aby wyczyścić katalogi \ bin i \ obj. Jednak gdy tylko wprowadzę więcej zmian w projektach niekompilujących, wszystko znów się nie powiedzie.

Ten problem również pojawił się podczas tworzenia nowego dodatku Microsoft Word w programie Visual Studio 2015. Problem dotyczy około 2 wersji MS Office, 2013 i 2016. Odinstalowuję MS Office 2013, a potem działa.

Tworzę kilka projektów dla SharePoint i oczywiście je wdrażam. Pewnego razu to się stało.

Znalazłem stary zestaw w C: \ Windows \ assembly \ temp \ xxx (z FarManager), usunąłem go po ponownym uruchomieniu i wszystkie projekty zostały zbudowane.

Mam pytanie do MSBuild, ponieważ w zestawach projektów połączonych jak projekty, a każdy zestaw jest oznaczony jako „Kopiuj lokalnie”, ale nie z GAC.

Jestem w stanie rozwiązać ten problem, zaznaczając „Kopiuj lokalnie = prawda” na wszystkich plikach DLL, do których istnieją odniesienia w projekcie, przebudowując i wdrażając na serwerze testowym.

Miałem problem z automapem. W binfolderze był plik automap.4net.dll, ale z jakiegoś powodu nie było plików automap.xml i automap.dll. Skopiowanie ich do binkatalogu rozwiązało problem.