Impossible de charger le type à partir d’une erreur d’assemblage

Est-ce que l’assembly dans le Global Assembly Cache (GAC) ou n’importe quel endroit peut remplacer l’assembly que vous pensez être chargé? Ceci est généralement le résultat d’un assemblage incorrect en cours de chargement, pour moi cela signifie que j’ai quelque chose dans le GAC qui remplace la version que j’ai dans bin / Debug.

Si vous avez un projet référençant un autre projet (tel qu’un type “Application Windows” faisant référence à une “Bibliothèque de classes”) et que les deux ont le même nom d’assemblage, vous obtenez cette erreur. Vous pouvez nommer fortement le projet référencé ou (encore mieux) renommer l’assemblage du projet référent (sous l’onglet ‘Application’ des propriétés du projet dans VS).

Désolé de draguer une vieille question à laquelle j’ai répondu, mais la solution pour moi n’était pas mentionnée ci-dessus, alors j’ai pensé append ma réponse à la longue queue …

J’ai fini par avoir une vieille référence à une classe (un HttpHandler) dans web.config qui n’était plus utilisée (et n’était plus une référence valide). Pour une raison quelconque, il a été ignoré lors de l’exécution dans Studio (ou peut-être que cette classe est toujours accessible dans mon installation de dev?) Et j’ai donc seulement eu cette erreur une fois que j’ai essayé de déployer sur IIS. J’ai recherché le nom de l’assembly dans web.config, supprimé la référence de gestionnaire inutilisée, puis cette erreur a disparu et tout fonctionne très bien. J’espère que ceci aide quelqu’un d’autre.

J’avais le même problème et pour moi, cela n’avait rien à voir avec un nom ou un espace de noms.

Mais comme plusieurs utilisateurs l’avaient laissé entendre, l’ancien ensemble était toujours référencé.

Je recommande de supprimer tous les dossiers “bin” / binary de tous les projets et de reconstruire la solution entière. Cela a éliminé tous les assemblages potentiellement obsolètes et après cela, MEF a exporté tous mes plugins sans problème.

J’avais cette erreur et je n’ai rien trouvé sur StackOverflow ou ailleurs, mais la réponse de bmoeskau à cette question m’a orienté dans la bonne direction pour le correctif, qui n’a pas encore été mentionné comme une réponse. Ma réponse n’est pas ssortingctement liée à la question originale, mais je la publie ici en supposant que quelqu’un ayant ce problème trouvera le moyen de le faire en effectuant une recherche sur Google ou quelque chose de similaire (comme moi un mois , arg!).

Mon assemblage est dans le GAC, il n’y a donc théoriquement qu’une seule version de l’assemblage disponible. Sauf qu’IIS met utilement en cache l’ancienne version et me donne cette erreur. Je venais de changer, de reconstruire et de réinstaller l’assemblage dans le GAC. Une solution possible consiste à utiliser le Gestionnaire des tâches pour supprimer w3wp.exe . Cela oblige IIS à relire l’assemblage à partir du GAC: problème résolu.

Lorsque je rencontre un tel problème, je trouve l’outil FUSLOGVW très utile. Il vérifie les informations de liaison de l’assemblage et les enregistre pour vous. Parfois, les bibliothèques sont manquantes, parfois GAC a des versions différentes en cours de chargement. Parfois, la plate-forme des bibliothèques référencées est à l’origine des problèmes. Cet outil montre clairement comment les liaisons des dépendances sont résolues et cela peut vraiment vous aider à parsingr / déboguer votre problème.

Afficheur de journaux de fusion / fuslogvw / Afficheur de journal de liaison d’assemblage. Vérifiez plus / téléchargez ici: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx .

Version = 1.0.3.0 indique Castle RC3, cependant l’interface courante a été développée quelques mois après la sortie de RC3. Par conséquent, il semble que vous ayez un problème de gestion des versions. Peut-être que Castle RC3 est enregistré dans le GAC et qu’il l’utilise …

Je reçois cela de temps en temps et il a toujours fallu que le assembly se fasse au GAC

Si cette erreur est due à la modification de l’espace de noms, assurez-vous que le dossier de ce projet est renommé et fermez VS.NET. Modifiez le projet qui rencontre le problème avec Notepad et remplacez-le par des nœuds.

“RootNamespace> New_Name_Of_Folder_Of_Your_Project_Namespace” RootNamespace> “AssemblyName> New_Name_Of_Folder_Of_Your_Project_Namespace” NomAssembly>

Il suffit de courir avec une autre cause:

exécution de tests unitaires en mode release mais la bibliothèque en cours de chargement était la version du mode debug qui n’avait pas été mise à jour

Il suffit de courir avec une autre cause:

J’utilisais un assemblage fusionné créé avec ILRepack. L’assembly à partir duquel vous interrogez les types doit être le premier transmis à ILRepack ou ses types ne seront pas disponibles.

J’ai eu le même problème. Je viens de résoudre ce problème en mettant à jour l’assemblage via GAC.

Pour utiliser gacutil sur une machine de développement, accédez à: Start -> programs -> Microsoft Visual studio 2010 -> Visual Studio Tools -> Visual Studio Command Prompt (2010) .

J’ai utilisé ces commandes pour désinstaller et réinstaller respectivement.

 gacutil /u myDLL gacutil /i "C:\Program Files\Custom\mydllname.dll" 

Note: je n’ai pas désinstallé mon dll dans mon cas, je viens de mettre à jour dll avec le chemin actuel.

La suppression de mon fichier .pdb pour la DLL a résolu ce problème pour moi. Je suppose que cela a quelque chose à voir avec le fait que la DLL a été créée en utilisant ILMerge.

J’ai eu ce problème après avoir factorisé un nom de classe:
Could not load type 'Namspace.OldClassName' from assembly 'Assembly name...'.

L’arrêt d’IIS et la suppression du contenu des Temporary ASP.NET Files résolus pour moi.

Dépendant de votre projet (version 32 / 64bit, .net, etc.), les Temporary ASP.NET Files appropriés sont différents:

• 64 bits
  %systemroot%\Microsoft.NET\Framework64\{.netversion}\Temporary ASP.NET Files\
• 32 bits
  %systemroot%\Microsoft.NET\Framework\{.netversion}\Temporary ASP.NET Files\
• Sur ma machine de développement c’était (parce que son IIS Express peut-être?)
  %temp%\Temporary ASP.NET Files

Peut-être pas aussi probable, mais pour moi cela a été causé par mon application essayant de charger une bibliothèque avec le même nom d’assembly (xxx.exe chargement xxx.dll).

J’ai rencontré ce scénario lorsque je tentais de charger un type (via la reflection) dans un assembly créé à partir d’une version différente d’une référence commune à l’application où cette erreur s’était produite.

Comme je suis sûr que le type est inchangé dans les deux versions de l’assemblage, j’ai fini par créer un résolveur d’assembly personnalisé qui mappe l’assembly manquant à celui que mon application a déjà chargé. Le moyen le plus simple consiste à append un constructeur statique à la classe de programme comme suit:

 using System.Reflection static Program() { AppDomain.CurrentDomain.AssemblyResolve += (sender, e) => { AssemblyName requestedName = new AssemblyName(e.Name); if (requestedName.Name == "") { // Load assembly from startup path return Assembly.LoadFile($"{Application.StartupPath}\\.dll"); } else { return null; } }; } 

Cela suppose bien sûr que l’assemblage se trouve dans le chemin de démarrage de l’application et puisse facilement être adapté.

Vous pourrez peut-être résoudre ce problème avec les redirections de liaison dans * .config. http://blogs.msdn.com/b/dougste/archive/2006/09/05/741329.aspx a une bonne discussion sur l’utilisation d’anciens composants .net dans les nouveaux frameworks. http://msdn.microsoft.com/en-us/library/eftw1fys(vs.71).aspx

Cela se produit généralement lorsque vous avez déployé une version de votre assembly dans le GAC, mais que vous ne l’avez pas mise à jour avec les nouvelles classes que vous avez éventuellement ajoutées à l’assembly sur votre IDE. Par conséquent, assurez-vous que l’assemblage sur le GAC est mis à jour avec les modifications que vous avez pu apporter à votre projet.

Par exemple, si vous avez une bibliothèque de classes de Common et dans cette bibliothèque de classes, vous avez le type Common.ClassA et déployez-le dans le nom du GAC. Vous venez plus tard et vous ajoutez un autre type appelé Common.ClassB et vous exécutez votre code sur votre IDE sans déployer au préalable les modifications apscopes au GAC of Common avec le type Common.ClassB nouvellement ajouté.

Encore une autre solution: les anciennes DLL pointant les unes vers les autres et mises en cache par Visual Studio dans

C:\Users\[yourname]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

Quittez VS, supprimez tout dans ce dossier et Bob est votre oncle.

J’ai eu la même erreur après la mise à jour d’une DLL référencée dans un projet exécutable de bureau. Le problème était que les personnes mentionnées ici évoquaient une ancienne référence et simple à corriger, mais n’avait pas été mentionnée ici, alors j’ai pensé que cela pourrait faire gagner du temps aux autres.

Quoi qu’il en soit, j’ai mis à jour dll A et obtenu l’erreur d’un autre dll référencé appelons-le B ici où dll A a une référence à dll B.

La mise à jour de dll B a résolu le problème.

Ajout de votre DLL au GAC (Global Assembly Cache)

Invite de commandes Visual Studio => Exécuter en tant qu’administrateur

gacutil / i “chemin du fichier dll”

Vous pouvez voir l’assembly ajouté C: \ Windows \ system32 \

Il permettra également de résoudre dll manquant ou “Impossible de charger le fichier ou l’assembly” dans la tâche de script SSIS

Je viens de résoudre ce problème en exécutant la commande iisreset en utilisant l’invite de commande … Toujours la première chose que je fais quand je reçois de telles erreurs.