Fehlermeldung 'Einer oder mehrere der angeforderten Typen können nicht geladen werden. Rufen Sie die LoaderExceptions-Eigenschaft ab, um weitere Informationen zu erhalten. '

Ich habe eine Anwendung mit Entity Framework , SQL Server 2000, Visual Studio 2008 und Enterprise Library entwickelt.

Es funktioniert lokal absolut einwandfrei, aber wenn ich das Projekt in unserer Testumgebung bereitstelle, wird der folgende Fehler angezeigt:

Einer oder mehrere der angeforderten Typen können nicht geladen werden. Rufen Sie die LoaderExceptions-Eigenschaft ab, um weitere Informationen zu erhalten

Stapelverfolgung: bei System.Reflection.Module._GetTypesInternal (StackCrawlMark & ​​stackMark)

bei System.Reflection.Assembly.GetTypes ()

at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly (LoadingContext-Kontext)

at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache (LoadingContext context)

at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache (Assembly Assembly, Boolean loadReferencedAssemblies, Dictionary2 knownAssemblies, Dictionary 2 & typesInLoading, List`1 & Fehler)

at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache (ObjectItemCollection objectItemCollection, Assembly Assembly, Boolean loadReferencedAssemblies)

at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType (Typ type)

at System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType (Typ Typ, Assembly aufrufenAssembly)

at System.Data.Objects.ObjectContext.CreateQuery [T] (String queryString, ObjectParameter [] -Parameter)

Entity Framework scheint ein Problem zu haben. Gibt es einen Hinweis, wie es behoben werden kann?

Ich habe dieses Problem gelöst, indem ich das Attribut "Lokal kopieren" der Referenzen meines Projekts auf "true" gesetzt habe.

Dieser Fehler hat keine echte Magic Bullet-Antwort. Der Schlüssel ist, alle Informationen zu haben, um das Problem zu verstehen. Höchstwahrscheinlich fehlt einer dynamisch geladenen Assembly eine referenzierte Assembly. Diese Assembly muss sich im bin-Verzeichnis Ihrer Anwendung befinden.

Verwenden Sie diesen Code, um festzustellen, was fehlt.

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

Eine Lösung, die für mich funktioniert hat, war, die Ordner bin / und obj / zu löschen und die Lösung neu zu erstellen.

Zwei mögliche Lösungen:

1. Sie kompilieren im Release-Modus, stellen jedoch eine ältere kompilierte Version aus Ihrem Debug-Verzeichnis bereit (oder umgekehrt).
2. In Ihrer Testumgebung ist nicht die richtige Version von .NET Framework installiert.

Wie bereits erwähnt, ist es normalerweise so, dass eine Baugruppe nicht vorhanden ist.

Um genau zu wissen, welche Assembly Sie vermissen, hängen Sie Ihren Debugger an, legen Sie einen Haltepunkt fest und führen Sie einen Drilldown zur Eigenschaft 'LoaderExceptions' durch, wenn Sie das Ausnahmeobjekt sehen. Die fehlende Baugruppe sollte vorhanden sein.

Ich hoffe es hilft!

Die Lösung bestand darin, die LoaderException zu überprüfen: In meinem Fall fehlten einige der DLL-Dateien.

Stellen Sie sicher, dass Sie 32-Bit-Anwendungen auf IIS zulassen, wenn Sie auf IIS bereitgestellt haben. Sie können dies in den Einstellungen Ihres aktuellen Anwendungspools definieren.

Ich habe diesen Fehler mit einem ASP.NET 4 + SQL Server 2008 R2 + Entity Framework festgestellt 4-Anwendung .

Es würde gut auf meinem Entwicklungscomputer (Windows Vista 64-Bit) funktionieren. Bei der Bereitstellung auf dem Server ( Windows Server 2008 R2 SP1) funktioniert dies bis zum Ablauf der Sitzung. Also haben wir die Anwendung bereitgestellt und alles sah gut aus und haben sie dann länger als 20 Minuten für die Sitzung belassen, und dann wurde dieser Fehler ausgelöst.

Um dieses Problem zu lösen, habe ich diesen Code in Ken Cox 'Blog verwendet , um die LoaderExceptions-Eigenschaft abzurufen.

Für meine Situation war die fehlende DLL Microsoft.ReportViewer.ProcessingObjectModel(Version 10). Diese DLL muss im GAC des Computers installiert sein, auf dem die Anwendung ausgeführt wird. Sie finden es im Microsoft Report Viewer 2010 Redistributable Package, das auf der Microsoft-Download-Site verfügbar ist.

Anfangs habe ich den Fusion Log Viewer ausprobiert, aber das hat nicht geholfen, und so habe ich WinDbg mit der SOS-Erweiterung verwendet.

! dumpheap -stat -type Ausnahme / D.

Dann habe ich die FileNotFoundExceptions untersucht. Die Nachricht in der Ausnahme enthielt den Namen der DLL, die nicht geladen wurde.

Hinweis: Mit / D erhalten Sie Ergebnisse mit Hyperlinks. Klicken Sie daher auf den Link in der Zusammenfassung für FileNotFoundException. Daraufhin wird eine Liste der Ausnahmen angezeigt. Klicken Sie dann auf den Link für eine der Ausnahmen. Das wird! Dumpobject diese Ausnahmen. Dann sollten Sie nur in der Lage sein, im Ausnahmeobjekt auf den Link für Nachricht zu klicken, und Sie sehen den Text.

Wenn Sie die EntityDataSource in Ihrem Projekt verwenden, befindet sich die Lösung in Fix: 'Einer oder mehrere der angeforderten Typen können nicht geladen werden' Fehler . Sie sollten ContextTypeName = "ProjectNameNameSpace.EntityContainerName" festlegen.

Dies löste meine Probleme ...

Meine Instanz dieses Problems war eine fehlende Referenz. Auf eine Assembly wurde in der app.config verwiesen, sie hatte jedoch keine Referenz im Projekt.

Wenn Sie Entity Framework verwenden , versuchen Sie, die folgenden Referenzen lokal zu kopieren.

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

Ändern Sie die Eigenschaft "Copy Local" für diese Referenzen in "True" und veröffentlichen Sie sie.

Eine andere Lösung, um zu wissen, warum genau nichts funktioniert (von Microsoft Connect):

1. Fügen Sie diesen Code zum Projekt hinzu:

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

2. Deaktivieren Sie Generierungsserialisierungsbaugruppen.

3. Erstellen und ausführen.

Ich hatte eine in Visual Studio 2010 entwickelte .NET 4.0-, ASP.NET MVC 2.0- und Entity Framework 4.0-Webanwendung. Ich hatte das gleiche Problem, dass sie auf einem Windows Server 2008 R2-Server, jedoch nicht auf einem anderen Windows Server 2008 R2-Server funktionierte. Obwohl die Versionen von .NET und ASP.NET MVC identisch waren, wurde derselbe Fehler wie bei Ihnen ausgegeben.

Ich bin dem Vorschlag von miko gefolgt und habe Windows SDK v7.1 (x64) auf dem fehlerhaften Server installiert , damit ich! Dumpheap ausführen kann.

Nun, es stellt sich heraus, dass die Installation des Windows SDK v7.1 (x64) das Problem behoben hat. Welche Abhängigkeit auch immer fehlte, muss im SDK enthalten sein. Es kann vom Microsoft Windows SDK für Windows 7 und .NET Framework 4 heruntergeladen werden .

Das Hinzufügen meines spezifischen Problems / meiner Lösung dazu, da dies das erste Ergebnis für diese Fehlermeldung ist. In meinem Fall wurde der Fehler empfangen, als ich eine zweite Anwendung im Ordner meiner ersten Anwendung in IIS bereitstellte . Beide definierten eine Verbindungszeichenfolge mit demselben Namen, was dazu führte, dass die untergeordnete Anwendung einen Konflikt hatte und diese (für mich) nicht offensichtliche Fehlermeldung generierte. Es wurde gelöst durch Hinzufügen von:

<clear/>

im Verbindungszeichenfolgenblock der untergeordneten Webanwendung, der verhindert hat, dass die Verbindungszeichenfolgen von web.config-Dateien höher in der Hierarchie geerbt werden, sieht es folgendermaßen aus:

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

Eine Referenzfrage zum Stapelüberlauf, die mir half, als ich feststellte, was los war, war: Wird eine untergeordnete Anwendung von ihrer übergeordneten web.config erben? .

Das hat bei mir funktioniert. Fügen Sie es in Ihre web.config ein

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

Mein Problem wurde behoben, nachdem ich die redundanten Assembly-Dateien aus dem binOrdner gelöscht habe .

Falls Ihnen keine der anderen Antworten hilft:

Als ich dieses Problem hatte, stellte sich heraus, dass mein Windows-Dienst für eine x64-Plattform erstellt wurde und ich versehentlich die 32-Bit-Version von InstallUtil.exe ausführte. Stellen Sie also sicher, dass Sie die richtige Version von InstallUtil für die Plattform verwenden, für die Sie erstellt haben.

Andere Vorschläge sind alle gut. In meinem Fall bestand das Problem darin, dass es sich bei der Entwicklerbox um einen 64-Bit-Computer handelte, der den x86-Speicherort verschiedener APIs einschließlich Silverlight verwendete .

Durch Ändern der Zielplattform auf den 32-Bit-Server, auf dem die Webanwendung bereitgestellt wurde, wurden die meisten Fehler behoben, die darauf zurückzuführen waren, dass einer oder mehrere der angeforderten Typen nicht geladen werden konnten.

Ich habe die spezifische Versionseigenschaft der Refrences in false geändert, und das hat geholfen.

Beim Kompilieren eines Visual Studio-Pakets (VSPackage) wurde dieselbe Fehlermeldung gemeldet. Die gesamte Lösung wird kompiliert und der Fehler wird ausgelöst, wenn das Paket von CreatePkgDef erstellt wird. Trotzdem ist klar, dass ich die LoaderExceptions nicht abfangen kann da es nicht meine Anwendung ist, , sondern das Microsoft-eigene Tool. (Obwohl ich für die Verwirrung von CreatePkgDef verantwortlich bin.)

In meinem Fall war die Hauptursache, dass meine Lösung eine MyDll.dll erstellt, die bereits im GAC registriert wurde (und sie sind unterschiedlich), sodass das CreatePgkDef verwirrt war, welches verwendet werden sollte, und es entschied, nur einen Fehler auszulösen, der nicht ' t wirklich hilfreich. Die MyDll.dll im GAC wurde vom Installationsprogramm desselben Produkts registriert (offensichtlich eine frühere Version mit / geringfügig / unterschiedlichem Inhalt).

Wie man es repariert

1. Bevorzugte Methode: Stellen Sie sicher, dass Sie die richtige Version von MyDll.dll verwenden
   2. Stellen Sie beim Kompilieren Ihres Projekts sicher, dass Sie eine andere Versionsnummer verwenden als in der vorherigen Version im GAC. Stellen Sie sicher, dass die folgenden Attribute korrekt sind:
      • [Assembly: AssemblyVersion ("1.0.0.1")] // Angenommen, die alte DLL-Datei wurde mit 1.0.0.0 versioniert
      • [Assembly: AssemblyFileVersion ("1.0.0.1")] // Angenommen, die alte DLL-Datei wurde mit 1.0.0.0 versioniert
   3. Geben Sie bei Bedarf den vollständig qualifizierten Assemblynamen an (z. B. "MyDll.dll, Version = 1.0.0.1, Culture = neutral, PublicKeyToken = 1234567890abcdef"), wenn Sie in Ihren anderen Projekten darauf verweisen.
2. Wenn das oben genannte fehlgeschlagen ist: Sie können die alte MyDll.dll von GAC deinstallieren
   1. So deinstallieren Sie eine Assembly vom GAC
   2. Deinstallieren Sie die Anwendung, die MyDll.dll enthält

Das Ändern der AssemblyVersion war gut genug für mich. :) :)

Ich hoffe das war hilfreich.

Ich hatte das gleiche Problem (aber auf meinem lokalen), als ich versuchte, die Entity Framework-Migration mit Package Manager Console hinzuzufügen.

Ich habe es gelöst, indem ich eine Konsolenanwendung erstellt habe, in der Main () den folgenden Code hatte:

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

Stellen Sie sicher, dass die Konfigurationsklasse die Migrationskonfiguration Ihres fehlgeschlagenen Projekts ist. Sie benötigen System.Data.Entity.Migrations, um DbMigrator verwenden zu können.

Legen Sie einen Haltepunkt in Ihrer Anwendung fest und führen Sie ihn aus. Die Ausnahme sollte von Visual Studio abgefangen werden (es sei denn, Sie haben diesen Ausnahmetyp so eingestellt, dass die Debugsitzung nicht unterbrochen wird), und Sie sollten in der Lage sein, die gesuchten Informationen zu finden.

Die fehlende Referenz in meinem Fall war EFProviderWrapperToolkit.

Ich habe dieses Problem erhalten, als ich ein NuGet- Paket in einem der Projekte installiert und vergessen habe, das andere Projekt zu aktualisieren.

Ich habe dieses Problem gelöst, indem ich beide Projekte mit derselben Referenzbaugruppe erstellt habe.

Das ist mir auch passiert. Ich habe das Problem wie folgt gelöst: Klicken Sie mit der rechten Maustaste auf Lösung, NuGet-Pakete für Lösung verwalten ... Konsolidieren Sie Pakete und aktualisieren Sie die Pakete auf dieselbe Version.

Setzen Sie den 32-Bit-IIS-Modus auf true, den Debug-Modus in der Konfigurationsdatei auf true. Durch Löschen des tempVerzeichnisses und Zurücksetzen von IIS wird das Problem vorübergehend behoben und es tritt nach einiger Zeit wieder auf.

Stellen Sie sicher, dass jedes Ihrer Projekte im Konfigurationsmanager korrekt eingerichtet ist .

Ähnlich wie bei William Edmondson Grund für dieses Problem habe ich meine Configuration Manager-Einstellung von "Debug" "Any CPU" auf "Debug" ".NET" geändert. Das Problem war, dass die ".NET" -Version NICHT so konfiguriert war, dass ALLE Projekte erstellt wurden, sodass einige meiner DLLs veraltet waren (während andere aktuell waren). Dies verursachte zahlreiche Probleme beim Starten der Anwendung.

Die vorübergehende Lösung bestand darin, Kenny Eliassons Vorschlag zu machen, die Verzeichnisse \ bin und \ obj zu bereinigen. Sobald ich jedoch weitere Änderungen an den nicht kompilierten Projekten vorgenommen habe, würde alles wieder fehlschlagen.

Dieses Problem trat auch beim Erstellen eines neuen Microsoft Word-Add-Ins mit Visual Studio 2015 auf. Bei diesem Problem handelt es sich um zwei Versionen von MS Office, 2013 und 2016. Ich deinstalliere MS Office 2013 und dann funktioniert es.

Ich habe einige Projekte für SharePoint erstellt und sie natürlich bereitgestellt. Einmal ist es passiert.

Ich habe eine alte Assembly in C: \ Windows \ Assembly \ Temp \ xxx (mit FarManager) gefunden, sie nach dem Neustart entfernt und alle Projekte erstellt.

Ich habe eine Frage an MSBuild, da in Projektassemblys, die wie Projekte verknüpft sind, jede Assembly mit "Lokal kopieren" gekennzeichnet ist, jedoch nicht aus dem GAC.

Ich kann dieses Problem beheben, indem ich "Copy Local = True" für alle referenzierten DLL-Dateien im Projekt markiere, neu erstelle und auf einem Testserver bereitstelle.

Ich hatte ein Problem mit Automap. In dem binOrdner befand sich die Datei automap.4net.dll, aus irgendeinem Grund jedoch nicht die Datei automap.xml und automap.dll. Durch Kopieren in das binVerzeichnis wurde das Problem behoben.