Messaggio di errore "Impossibile caricare uno o più dei tipi richiesti. Recupera la proprietà LoaderExceptions per ulteriori informazioni. "

Ho sviluppato un'applicazione usando Entity Framework , SQL Server 2000, Visual Studio 2008 ed Enterprise Library.

Funziona perfettamente a livello locale, ma quando distribuisco il progetto nel nostro ambiente di test, visualizzo il seguente errore:

Impossibile caricare uno o più dei tipi richiesti. Recupera la proprietà LoaderExceptions per ulteriori informazioni

Stack trace: at System.Reflection.Module._GetTypesInternal (StackCrawlMark & ​​stackMark)

at System.Reflection.Assembly.GetTypes ()

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

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

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

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

at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType (Tipo tipo)

at System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType (Tipo di tipo, Assembly callingAssembly)

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

Entity Framework sembra avere problemi, qualche indizio su come risolverlo?

Ho risolto questo problema impostando l'attributo Copia locale dei riferimenti del mio progetto su true.

Questo errore non ha una vera risposta al proiettile magico. La chiave è avere tutte le informazioni per capire il problema. Molto probabilmente a un assembly caricato dinamicamente manca un assembly a cui viene fatto riferimento. Tale assembly deve trovarsi nella directory bin dell'applicazione.

Usa questo codice per determinare cosa manca.

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

Una soluzione che ha funzionato per me era eliminare le cartelle bin / e obj / e ricostruire la soluzione.

Due possibili soluzioni:

1. Stai compilando in modalità Rilascio ma stai distribuendo una versione compilata precedente dalla tua directory di debug (o viceversa).
2. Non hai la versione corretta di .NET Framework installata nel tuo ambiente di test.

Come è stato menzionato prima, di solito è il caso di un'assemblea che non c'è.

Per sapere esattamente quale assembly manchi, collega il tuo debugger, imposta un punto di interruzione e quando vedi l'oggetto eccezione, esegui il drill down sulla proprietà 'LoaderExceptions'. L'assemblea mancante dovrebbe essere lì.

Spero che sia d'aiuto!

La soluzione era quella di verificare LoaderException: nel mio caso mancavano alcuni file DLL.

Assicurarsi di consentire le applicazioni a 32 bit su IIS se è stato distribuito su IIS. Puoi definirlo sulle impostazioni del tuo attuale pool di applicazioni.

Ho riscontrato questo errore con un'applicazione ASP.NET 4 + SQL Server 2008 R2 + Entity Framework 4.

Funzionerebbe benissimo sulla mia macchina di sviluppo (Windows Vista 64-bit). Quindi, quando distribuito sul server ( Windows Server 2008 R2 SP1), funzionerebbe fino al timeout della sessione. Quindi avremmo distribuito l'applicazione e tutto sembrava a posto e poi l'avremmo lasciato per più di 20 minuti di timeout della sessione e quindi sarebbe stato generato questo errore.

Per risolverlo, ho usato questo codice sul blog di Ken Cox per recuperare la proprietà LoaderExceptions.

Per la mia situazione la DLL mancante era Microsoft.ReportViewer.ProcessingObjectModel(versione 10). Questa DLL deve essere installata nel GAC del computer su cui viene eseguita l'applicazione. Puoi trovarlo nel pacchetto ridistribuibile di Microsoft Report Viewer 2010 disponibile sul sito di download di Microsoft.

Inizialmente ho provato il visualizzatore di log di Fusion, ma questo non mi ha aiutato, quindi ho finito per usare WinDbg con l'estensione SOS.

! dumpheap -stat -type Eccezione / D

Quindi ho esaminato FileNotFoundExceptions. Il messaggio nell'eccezione conteneva il nome della DLL che non si stava caricando.

NB, la / D ti dà i risultati del collegamento ipertestuale, quindi fai clic sul collegamento nel riepilogo per FileNotFoundException. Verrà visualizzato un elenco delle eccezioni. Quindi fare clic sul collegamento per una delle eccezioni. Quello! Dumpobject che eccezioni. Quindi dovresti solo essere in grado di fare clic sul collegamento per Messaggio nell'oggetto eccezione e vedrai il testo.

Se stai usando EntityDataSource nel tuo progetto, la soluzione è in Fix: "Impossibile caricare uno o più dei tipi richiesti" Errori . È necessario impostare ContextTypeName = "ProjectNameNameSpace.EntityContainerName" '

Questo ha risolto i miei problemi ...

La mia istanza di questo problema è risultata essere un riferimento mancante. Un assembly era indicato in app.config ma non aveva un riferimento nel progetto.

Se si utilizza Entity Framework , provare a copiare localmente i seguenti riferimenti.

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

Modificare la proprietà "Copia locale" su "Vero" per questi riferimenti e pubblicare.

Un'altra soluzione per sapere perché non funziona esattamente nulla (da Microsoft Connect):

1. Aggiungi questo codice al progetto:

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

2. Disattiva gli assiemi di serializzazione di generazione.

3. Costruisci ed esegui.

Avevo un'applicazione .NET 4.0, ASP.NET MVC 2.0, Entity Framework 4.0 sviluppata in Visual Studio 2010. Ho avuto lo stesso problema, che funzionava su un server Windows Server 2008 R2 ma non su un altro server Windows Server 2008 R2, anche se le versioni di .NET e ASP.NET MVC erano le stesse, generando questo stesso errore.

Sono andato a seguire il suggerimento di miko, quindi ho installato Windows SDK v7.1 (x64) sul server in errore, in modo da poter eseguire! Dumpheap.

Bene, si scopre che l'installazione di Windows SDK v7.1 (x64) ha risolto il problema. Qualunque dipendenza mancasse deve essere stata inclusa nell'SDK. Può essere scaricato da Microsoft Windows SDK per Windows 7 e .NET Framework 4 .

Aggiungendo il mio problema specifico / soluzione a questo in quanto questo è il primo risultato per questo messaggio di errore. Nel mio caso, l'errore è stato ricevuto quando ho distribuito una seconda applicazione nella cartella della mia prima applicazione in IIS . Entrambi definivano la stringa di connessione con lo stesso nome, causando un conflitto nell'applicazione figlio e generando a sua volta questo (per me) messaggio di errore non ovvio. È stato risolto aggiungendo:

<clear/>

nel blocco di stringhe di connessione dell'applicazione Web figlio che gli ha impedito di ereditare le stringhe di connessione dei file web.config più in alto nella gerarchia, quindi sembra:

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

Una domanda di riferimento di Stack Overflow che mi ha aiutato una volta determinato che cosa stava succedendo è stata un'applicazione ereditata dal suo web.config padre? .

Questo ha funzionato per me. Aggiungilo nel tuo web.config

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

Il mio problema è stato risolto dopo aver eliminato i file assembly ridondanti dalla bincartella.

Nel caso in cui nessuna delle altre risposte ti aiuti:

Quando ho avuto questo problema, ho scoperto che il mio servizio Windows è stato creato per una piattaforma x64 e inavvertitamente stavo eseguendo la versione a 32 bit di InstallUtil.exe. Quindi assicurati di utilizzare la versione corretta di InstallUtil per la piattaforma che hai creato.

Altri suggerimenti sono tutti buoni. Nel mio caso, il problema era che la casella dello sviluppatore era una macchina a 64 bit che utilizzava la posizione x86 di varie API, tra cui Silverlight .

Modificando la piattaforma di destinazione in modo che corrisponda al server a 32 bit in cui è stata distribuita l'applicazione Web, è stata rimossa la maggior parte degli errori relativi alla mancata possibilità di caricare uno o più dei tipi richiesti.

Ho modificato la proprietà della versione specifica dei riferimenti in false e ciò mi ha aiutato.

Ho avuto lo stesso messaggio di errore riportato durante la compilazione di un pacchetto di Visual Studio (VSPackage). L'intera soluzione viene compilata e l'errore viene generato quando il pacchetto viene creato da CreatePkgDef. Detto questo, è chiaro che non riesco a catturare LoaderExceptions in quanto non è la mia applicazione a lanciarlo, ma lo strumento di Microsoft. (Anche se sono responsabile della confusione di CreatePkgDef.)

Nel mio caso la causa principale è stata che la mia soluzione crea un MyDll.dll che è già stato registrato nel GAC (e sono diversi), quindi CreatePgkDef si è confuso quale usare e ha deciso di lanciare un errore che non è davvero utile. MyDll.dll nel GAC è stato registrato dall'installatore dello stesso prodotto (ovviamente una versione precedente, con / leggermente / contenuto diverso).

Come sistemarlo

1. Modo preferito: assicurarsi di utilizzare la versione corretta di MyDll.dll
   2. Durante la compilazione del progetto, assicurarsi di utilizzare un numero di versione diverso da quello utilizzato nella versione precedente situata nel GAC. Assicurarsi che i seguenti attributi siano corretti:
      • [assembly: AssemblyVersion ("1.0.0.1")] // Supponendo che il vecchio file DLL fosse aggiornato alla versione 1.0.0.0
      • [assembly: AssemblyFileVersion ("1.0.0.1")] // Supponendo che il vecchio file DLL fosse aggiornato alla versione 1.0.0.0
   3. Se necessario, specificare il nome dell'assembly completo (ad esempio "MyDll.dll, Versione = 1.0.0.1, Cultura = neutro, PublicKeyToken = 1234567890abcdef") quando lo si fa riferimento in altri progetti.
2. Se quanto sopra non è riuscito: è possibile disinstallare il vecchio MyDll.dll da GAC
   1. Come disinstallare un assembly dal GAC
   2. Disinstallare l'applicazione che include MyDll.dll

Cambiare AssemblyVersion è stato abbastanza buono per me. :)

Spero sia stato utile.

Ho avuto lo stesso problema (ma sul mio locale) quando stavo provando ad aggiungere la migrazione di Entity Framework con la console di Package Manager.

Il modo in cui l'ho risolto è stato creando un'applicazione console in cui Main () aveva il seguente codice:

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

Assicurarsi che la classe di configurazione sia la configurazione di migrazione del progetto in errore. Per utilizzare DbMigrator è necessario System.Data.Entity.Migrations.

Impostare un punto di interruzione nell'applicazione ed eseguirlo. L'eccezione dovrebbe essere rilevata da Visual Studio (a meno che tu non abbia impostato quel tipo di eccezione per non interrompere la sessione di debug) e dovresti essere in grado di trovare le informazioni che stai cercando.

Il riferimento mancante nel mio caso era EFProviderWrapperToolkit.

Ho riscontrato questo problema quando ho installato un pacchetto NuGet su uno dei progetti e ho dimenticato di aggiornare l'altro progetto.

Ho risolto questo problema facendo in modo che entrambi i progetti avessero lo stesso assieme di riferimento.

È successo anche a me. Ho risolto il problema nel modo seguente: Fare clic con il pulsante destro del mouse su Soluzione, Gestisci pacchetti NuGet per soluzione ... Consolidare i pacchetti e aggiornare i pacchetti in modo che siano nella stessa versione.

Impostare la modalità IIS a 32 bit su true, la modalità di debug su true nel file di configurazione, l'eliminazione della tempdirectory e il ripristino di IIS risolvono temporaneamente il problema e si ripresenta dopo qualche tempo.

Verifica che ciascuno dei tuoi progetti sia impostato correttamente in Configuration Manager .

Simile al motivo di William Edmondson per questo problema, ho cambiato l'impostazione di Configuration Manager da "Debug" "Any CPU" a "Debug" ".NET". Il problema era che la versione ".NET" NON era configurata per compilare TUTTI i progetti, quindi alcune delle mie DLL erano obsolete (mentre altre erano aggiornate). Ciò ha causato numerosi problemi con l'avvio dell'applicazione.

La soluzione temporanea era quella di dare il suggerimento di Kenny Eliasson di ripulire le directory \ bin e \ obj. Tuttavia, non appena avessi apportato ulteriori modifiche ai progetti non compilanti, tutto sarebbe nuovamente fallito.

Ho riscontrato questo problema anche quando creo un nuovo componente aggiuntivo di Microsoft Word con Visual Studio 2015. Il problema è che ho 2 versioni di MS Office, 2013 e 2016. Disinstallo MS Office 2013 e poi funziona.

Realizzo alcuni progetti per SharePoint e, naturalmente, li ho distribuiti. Una volta è successo.

Ho trovato un vecchio assembly in C: \ Windows \ assembly \ temp \ xxx (con FarManager), rimosso dopo il riavvio e tutti i progetti creati.

Ho una domanda per MSBuild, perché negli assiemi di progetto collegati come progetti e ogni assemblaggio è contrassegnato come "Copia locale", ma non dal GAC.

Sono in grado di risolvere questo problema contrassegnando "Copia locale = True" su tutti i file DLL di riferimento nel progetto, ricostruendo e distribuendo su un server di prova.

Ho avuto un problema con automap. Nella bincartella era presente il file automap.4net.dll, ma per qualche motivo non erano presenti automap.xml e automap.dll. Copiandoli nella bindirectory risolto il problema.