Message d'erreur 'Impossible de charger un ou plusieurs des types demandés. Récupérez la propriété LoaderExceptions pour plus d'informations. '
J'ai développé une application utilisant Entity Framework , SQL Server 2000, Visual Studio 2008 et Enterprise Library.
Cela fonctionne parfaitement localement, mais lorsque je déploie le projet dans notre environnement de test, le message d'erreur suivant s'affiche:
Impossible de charger un ou plusieurs des types demandés. Récupérer la propriété LoaderExceptions pour plus d'informations
Trace de pile: à System.Reflection.Module._GetTypesInternal (StackCrawlMark & stackMark)
à System.Reflection.Assembly.GetTypes ()
sur System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly (contexte LoadingContext)
sur System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache (contexte LoadingContext)
sur System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache (Assembly Assembly, Boolean loadReferencedAssemblies, Dictionary
2 knownAssemblies, Dictionary2 & typesInLoading, List`1 & errors)sur System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache (ObjectItemCollection objectItemCollection, Assembly Assembly, Boolean loadReferencedAssemblies)
sur System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType (Type type)
sur System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType (Type, Assembly callAssembly)
at System.Data.Objects.ObjectContext.CreateQuery [T] (paramètres String queryString, ObjectParameter [])
Entity Framework semble avoir un problème, aucun indice sur la façon de le résoudre?
J'ai résolu ce problème en définissant l'attribut Copier en local des références de mon projet sur true.
Cette erreur n'a pas de vraie réponse magique. La clé est d'avoir toutes les informations pour comprendre le problème. Il est fort probable qu'un assembly référencé manque dans un assembly chargé de manière dynamique. Cet assemblage doit se trouver dans le répertoire bin de votre application.
Utilisez ce code pour déterminer ce qui manque.
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.
}
Une solution qui a fonctionné pour moi a été de supprimer les dossiers bin/et obj/et de reconstruire la solution.
Deux solutions possibles:
- Vous compilez en mode Release mais déployez une version compilée plus ancienne à partir de votre répertoire Debug (ou inversement).
- La version correcte du .NET Framework n'est pas installée dans votre environnement de test.
Comme cela a déjà été mentionné, il s’agit généralement d’une Assemblée absente.
Pour savoir exactement quel assemblage vous manque, attachez votre débogueur, définissez un point d'arrêt et, lorsque vous voyez l'objet exception, accédez à la propriété 'LoaderExceptions'. L'assemblée manquante devrait être là.
J'espère que ça aide!
J'ai rencontré cette erreur avec une application ASP.NET 4 + SQL Server 2008 R2 + Entity Framework 4.
Cela fonctionnerait bien sur ma machine de développement (Windows Vista 64 bits). Ensuite, lorsqu'il est déployé sur le serveur ( Windows Server 2008 R2 SP1), il fonctionnera jusqu'à expiration de la session. Nous allions donc déployer l'application et tout avait l'air d'aller bien, puis la laisser pendant plus de 20 minutes, puis l'erreur serait renvoyée.
Pour le résoudre, j'ai utilisé ce code sur le blog de Ken Cox pour récupérer la propriété LoaderExceptions.
Pour ma situation, la DLL manquante était Microsoft.ReportViewer.ProcessingObjectModel (version 10). Ce DLL doit être installé dans le GAC de la machine sur laquelle l'application est exécutée. Vous pouvez le trouver dans le package redistribuable de Microsoft Report Viewer 2010 disponible sur le site de téléchargement de Microsoft.
Assurez-vous d'autoriser les applications 32 bits sur IIS si vous avez déployé sur IIS. Vous pouvez définir cela dans les paramètres de votre pool d'applications actuel.
Si vous utilisez EntityDataSource dans votre projet, la solution est dans Correction: 'Impossible de charger un ou plusieurs des types demandés' Erreurs. Vous devez définir le ContextTypeName = "ProjectNameNameSpace.EntityContainerName" '
Cela a résolu mes problèmes ...
La solution consistait à vérifier l'exception LoaderException: dans mon cas, certains des fichiers DLL étaient manquants.
Au départ, j'ai essayé le visualiseur de journaux Fusion, mais cela ne m'a pas aidé. J'ai donc utilisé WinDbg avec l'extension SOS.
! dumpheap -stat -type -Exception/D
Ensuite, j'ai examiné les exceptions FileNotFoundExceptions. Le message dans l'exception contenait le nom du DLL qui n'était pas chargé.
NB, le/D vous donne des résultats en hyperlien, alors cliquez sur le lien dans le récapitulatif de FileNotFoundException. Cela fera apparaître une liste des exceptions. Cliquez ensuite sur le lien pour l'une des exceptions. Cela va! Dumpobject que exceptions. Ensuite, vous devriez pouvoir cliquer sur le lien Message dans l’objet exception et vous verrez le texte.
Mon exemple de ce problème a fini par être une référence manquante. Une assemblée était mentionnée dans app.config mais n'avait pas de référence dans le projet.
Une autre solution pour savoir pourquoi rien ne fonctionne (à partir de Microsoft connect):
Ajoutez ce code au projet:
foreach (var asm in AppDomain.CurrentDomain.GetAssemblies()) { asm.GetTypes(); }Désactiver les assemblys de sérialisation de génération.
- Construire et exécuter.
Ajout de mon problème spécifique/solution à cela car c'est le premier résultat pour ce message d'erreur. Dans mon cas, l'erreur a été reçue lorsque j'ai déployé une deuxième application dans le dossier de ma première application dans IIS . Tous deux définissaient une chaîne de connexion avec le même nom, ce qui entraînait un conflit entre l'application enfant et générait à son tour ce message d'erreur non évident (pour moi). Cela a été résolu en ajoutant:
<clear/>
dans le bloc de chaîne de connexion de l'application Web enfant, ce qui l'a empêchée d'hériter des chaînes de connexion des fichiers web.config situés plus haut dans la hiérarchie, de sorte que:
<connectionStrings>
<clear/>
<add name="DbContext" connectionString="MySERVER" providerName="System.Data.SqlClient" />
</connectionStrings>
Une question de référence Stack Overflow qui m'a aidé une fois que j'ai déterminé ce qui se passait Était Une application enfant va-t-elle hériter de son parent web.config?.
Cela a fonctionné pour moi. Ajoutez-le dans votre web.config
<system.web>
<trust level="Full" />
Si aucune des autres réponses ne vous aide:
Lorsque j'ai eu ce problème, il s'est avéré que mon service Windows était conçu pour une plate-forme x64 et que j'exécutais par inadvertance la version 32 bits de InstallUtil.exe. Assurez-vous donc que vous utilisez la bonne version de InstallUtil pour la plate-forme pour laquelle vous avez construit.
J'ai eu ce problème lorsque j'ai installé un package NuGet sur l'un des projets et que j'ai oublié de mettre à jour l'autre projet.
J'ai résolu ce problème simplement en faisant en sorte que les deux projets aient la même assemblée de référence.
J'avais le même problème (mais au niveau local) lorsque j'essayais d'ajouter la migration Entity Framework avec Package Manager Console.
La façon dont j'ai résolu le problème était de créer une application console où Main () avait le code suivant:
var dbConfig = new Configuration();
var dbMigrator = new DbMigrator(dbConfig);
dbMigrator.Update();
Assurez-vous que la classe de configuration correspond à la configuration de migration de votre projet défaillant. Vous aurez besoin de System.Data.Entity.Migrations pour utiliser DbMigrator.
Définissez un point d'arrêt dans votre application et exécutez-le. L'exception doit être interceptée par Visual Studio (sauf si ce type d'exception est défini pour ne pas interrompre la session de débogage) et vous devriez pouvoir trouver les informations que vous recherchez.
La référence manquante dans mon cas était EFProviderWrapperToolkit.
J'avais un .NET 4.0, ASP.NET MVC 2.0, Application Web Entity Framework 4.0 développée dans Visual Studio 2010. J'ai eu le même problème, qu'il fonctionnait sur un Windows Server 2008 Serveur R2 mais pas sur un autre serveur Windows Server 2008 R2, même si les versions de .NET et ASP.NET MVC étaient identiques, générant la même erreur que la vôtre.
Je suis allé suivre la suggestion de miko et j'ai donc installé Windows SDK v7.1 (x64) sur le serveur défaillant pour pouvoir exécuter! Dumpheap.
Eh bien, il s’avère que l’installation de Windows SDK v7.1 (x64) a résolu le problème. Toute dépendance manquante devait avoir été incluse dans le SDK. Il peut être téléchargé à partir du SDK Microsoft Windows pour Windows 7 et .NET Framework 4.
C'est arrivé pour moi aussi. J'ai résolu le problème de la manière suivante:.
Mon problème a été résolu après la suppression des fichiers d'assemblage redondants du dossier bin.
Les autres suggestions sont toutes bonnes. Dans mon cas, le problème était que la boîte de développement était une machine 64 bits utilisant l'emplacement x86 de diverses API, y compris Silverlight .
En modifiant la plate-forme cible pour qu'elle corresponde au serveur 32 bits sur lequel l'application Web était déployée, la plupart des erreurs liées à l'impossibilité de charger un ou plusieurs types demandés ont été supprimées.
Si vous utilisez Entity Framework , essayez de copier les références suivantes localement.
- System.Data.Entity
- System.Web.Entity
Modifiez la propriété "Copier local" en "Vrai" pour ces références et publiez.
J'ai changé la propriété de version spécifique des références en false et cela a aidé.
J'ai rencontré ce problème avec l'entité framework lors de la saisie des commandes de migration dans la console Nuget.
le problème est apparu lorsque j'ai déplacé mesOAuthAuthorizationServerProvidercodes de mon application vers un projet de bibliothèque de classes contenant la logique d'accès aux données de base ainsi que ma classe DBContext.
Je vérifie toutes mes DLL référencées par le projet de bibliothèque de classes. et pour tous (sauf les DLL système .net) CopyToLocal était vrai, j'étais complètement confus.
Je savais qu'il y avait quelque chose qui n'allait pas avec les DLL elles-mêmes, pas avec mes codes. Je les ai vérifiées à nouveau et j'ai remarqué que lorsque j'ai déplacé maApplicationOauthProviderclass dans un projet de bibliothèque de classes, laApplicationOauthProviderhérite deOAuthAuthorizationServerProviderclass qui se trouve dansMicrosoft.Owin.Security.OAuthAssembly, j'ai coché c'est la version du paquet et soudainement remarqué que la version du paquet que j'ai utilisée pour le projet de bibliothèque de classes (pas mon projet d'application) est très ancienne 2.1, mais sur mon application la dernière version a été installée (3.0.1), donc j'ai mis à jour la version duMicrosoft.Owin.Security.OAuthpackage de Nuget pour mon projet de bibliothèque de classe et problème résolu
En bref, après avoir vérifiéCopyToLocal, la propriété de vos DLL vérifie aussi leurs versions et met à jour les anciennes pour les laisser
Je suis en mesure de résoudre ce problème en cochant "Copie locale = Vrai" sur tous les fichiers DLL référencés du projet, en reconstruisant et en déployant sur un serveur de test.
Dans mon cas, un paquet de nuget était installé dans mon projet, mais le dossier du paquet n'a jamais été archivé dans TFS. Par conséquent, dans la machine de construction, les fichiers bin du paquet de nuget étaient manquants. Et par conséquent, en production, j'ai eu cette erreur. Je devais comparer le dossier bin par rapport à la production par rapport à mon local puis j’ai trouvé les dll manquantes et j’ai trouvé que celles-ci appartenaient à un seul paquet de pépites.
J'ai eu un problème avec automap. Dans le dossier bin, le fichier automap.4net.dll était présent, mais pour une raison quelconque, les fichiers automap.xml et automap.dll n'y étaient pas. Les copier dans le répertoire bin a résolu le problème.
J'ai eu ce problème en faisant référence à un paquet de nuget et en utilisant plus tard l'option remove pour le supprimer de mon projet. J'ai dû vider le dossier bin après avoir lutté pendant des heures avec le problème. Pour éviter cela, il est conseillé d’utiliser nuget pour désinstaller les paquets indésirables au lieu de la suppression habituelle.
J'ai également eu ce problème lors de la création d'un complément Microsoft Word avec Visual Studio 2015. Il concerne deux versions de MS Office, 2013 et 2016. Je désinstalle MS Office 2013, puis tout fonctionne.
J'ai reçu le même message d'erreur lors de la compilation d'un package Visual Studio (VSPackage). La solution entière est compilée et l'erreur est générée lors de la création du package par CreatePkgDef. Cela dit, il est clair que je ne peux pas saisir les exceptions LoaderExceptions} car ce n’est pas mon application qui le jette, mais le propre outil de Microsoft. (Bien que je sois responsable de la confusion de CreatePkgDef.)
Dans mon cas, la cause racine était que ma solution crée un fichier MyDll.dll déjà enregistré sur le GAC (et ils sont différents), de sorte que CreatePgkDef a confondu lequel utiliser et il a simplement décidé de jeter une erreur qui n'est pas vraiment utile. Le fichier MyDll.dll du GAC a été enregistré par le programme d'installation du même produit (évidemment une version antérieure, avec un contenu légèrement/différent).
Comment le réparer
- Méthode préférée: _ Assurez-vous d'utiliser la version correcte de MyDll.dll} _
- Lors de la compilation de votre projet, veillez à utiliser un numéro de version différent de celui utilisé dans la version précédente située dans le GAC. Assurez-vous que les attributs suivants sont corrects:
- [Assembly: AssemblyVersion ("1.0.0.1")] // En supposant que l'ancien fichier DLL était version 1.0.0.0
- [Assembly: AssemblyFileVersion ("1.0.0.1")] // En supposant que l'ancien fichier DLL était version 1.0.0.0
- Si nécessaire, spécifiez le nom d'assembly qualifié complet (par exemple, "MyDll.dll, version = 1.0.0.1, Culture = neutre, PublicKeyToken = 1234567890abcdef") lorsque vous le référencerez dans vos autres projets.
- Lors de la compilation de votre projet, veillez à utiliser un numéro de version différent de celui utilisé dans la version précédente située dans le GAC. Assurez-vous que les attributs suivants sont corrects:
- Si l'échec ci-dessus a échoué: _ vous pouvez désinstaller l'ancien MyDll.dll de GAC
- Comment désinstaller un assembly du GAC
- Désinstallez l'application qui inclut MyDll.dll
Changer la version d'assemblage me suffisait. :)
J'espère que cela a été utile.
Je mettais à jour un site Web via FTP. Je suppose que le site Web était en cours d'utilisation et que, lors de la tentative de mise à jour du dossier bin, quelques fichiers DLL doivent avoir été verrouillés et ne pas être mis à jour.
Là, j'ai vu l'erreur 500 et le réglage du mode customErrors sur Off, ainsi que le message d'erreur mentionné par l'OP.
Le problème était que je n'ai pas vu les échecs répertoriés dans le programme FTP. J'ai retenté ces échecs échoue et ils ont téléchargé. Le dernier fichier DLL mis à jour. Donc, le site a ensuite fonctionné.
Vérifiez que chacun de vos projets est configuré correctement dans Configuration Manager.
Comme pour la raison William Edmondson _ de ce problème, j'ai remplacé le paramètre "Debug" "" Tout processeur "par Configuration Manager par" Debug "" ".NET". Le problème était que la version ".NET" n'était PAS configurée pour générer TOUS les projets. Certaines de mes DLL étaient donc obsolètes (tandis que d'autres étaient actuelles). Cela a causé de nombreux problèmes lors du démarrage de l'application.
La solution temporaire consistait à faire la suggestion de { Kenny Eliasson } _ de nettoyer les répertoires\bin et\obj. Cependant, dès que j'apporterais des modifications supplémentaires aux projets ne faisant pas partie de la compilation, tout échouerait à nouveau.
Je construis quelques projets pour SharePoint et, bien sûr, je les ai déployés. Une fois c'est arrivé.
J'ai trouvé un ancien assembly dans C:\Windows\Assembly\temp\xxx (avec FarManager), je l'ai supprimé après le redémarrage et tous les projets construits.
J'ai une question pour MSBuild, car dans les assemblys de projet liés comme des projets, chaque assemblée est marquée "Copier en local", mais pas du GAC.
Définissez le mode 32 bits IIS sur true, le mode débogage sur true dans le fichier de configuration, la suppression du répertoire temp et la réinitialisation de IIS corrigent le problème de manière temporelle, puis revient au bout d'un certain temps.