Windows Form Designer: impossible de charger le fichier ou l’assembly

Quelqu’un a-t-il déjà rencontré le problème suivant: l’erreur “Impossible de charger le fichier ou l’assembly …” lors de la tentative de “Visualiser” sur un formulaire Windows dans Visual Studio .NET?

Dans ce cas, l’assembly en question était XYZ.dll . J’ai réussi à résoudre ce problème en ajoutant XYZ.dll et toutes ses références aux références de mon projet (même si mon projet ne dépend pas directement d’eux) et en reconstruisant toute la solution. Cependant, après cela, j’ai retiré toutes les références de mon projet, reconstruites, et cela fonctionnait toujours.

Une autre information est que j’utilise Resharper 2.5 . Quelqu’un d’autre a fait remarquer que cela pourrait être Resharper en train de faire des copies d’ombre. Je vais regarder dans la prochaine fois que cela se produit. Est-ce que quelqu’un a compris pourquoi cette erreur se produit en premier lieu, et peut-être la manière «correcte» de la réparer?

Nous avons le même problème. Certaines classes Form / UserControl ne peuvent pas être affichées dans le concepteur et Visual Studio provoque diverses exceptions.

Il existe une cause typique: Un composant conçu a généré une exception non gérée lors de l’initialisation (dans un constructeur ou dans un événement Load ou avant).

Non seulement dans ce cas, vous pouvez exécuter une autre instance de Visual Studio, ouvrir / créer un projet indépendant, aller dans le menu -> Debug -> Attach to process … -> sélectionner une instance du processus devenv.exe avec un concepteur problématique. Ensuite, appuyez sur Ctrl + Alt + E , les fenêtres “Exceptions” doivent être affichées. Cochez “Thrown” dans les catégories d’exception.

Activez maintenant le studio visuel avec le concepteur et essayez le concepteur de vue. Si l’exception est levée, vous verrez apparaître callstack (et peut-être le code source, si l’exception a été émise à partir de votre code) et d’autres informations typiques sur l’exception renvoyée. Cette information peut être très utile.

C’est une vieille question qui semble toujours ne pas avoir de réponse, que ce soit ici ou dans le pool de forum plus large, la plupart des conseils se rapportent à des “cleans” reconstruits ou à des dossiers propres> rouvrir ou redémarrer la machine. Je n’ai pas de réponse solide à l’heure actuelle, mais j’ai fait des recherches et pensé que je pourrais partager. En résumé, il existe un emplacement dans lequel tous les fichiers de concepteur sont copiés lors de la conception d’un contrôle ou d’un formulaire, un autre emplacement contenant d’anciens fichiers et une méthode permettant de détecter toutes les exceptions avant que le concepteur puisse générer la page d’erreur.

Il semble y avoir deux cas où un assemblage ne peut pas être chargé ou est introuvable. Le premier est dû au fait que les fichiers ne parviennent pas à copier vers les emplacements requirejs par le concepteur, le second concerne les fichiers obsolètes qui restnt.

Comme mentionné ci-dessus, les fichiers ne parviennent pas à copier lorsqu’un projet ne fait pas directement référence à toutes les références requirejses par ses références référencées et à leurs références, récursivement, jusqu’au framework. Cela peut être atténué en suivant attentivement toutes les références et leurs personnes à charge, en veillant à ce que tout soit pris en compte.

Le concepteur Visual Studio utilise un emplacement spécifique pour mettre en cache les DLL pour son utilisation dans le concepteur, isolé des dossiers source / bin des projets:

Windows XP:

C: \ Documents and Settings \ [nom_utilisateur] \ Paramètres locaux \ Application Data \ Microsoft \ VisualStudio \ 10.0 \ ProjectAssemblies

Windows 7:

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

Dans cet emplacement, les assemblys compilés sont copiés dans des dossiers créés dynamicment , un dossier par assemblage. En vérifiant les dates de la version de l’assemblage à cet emplacement, il semble être assez à jour, étant supprimé lorsque le studio visuel se ferme. Tous les assemblys sont copiés lorsqu’un concepteur est visualisé avec des fichiers nouvellement compilés. Une nouvelle copie de chaque assemblage est créée dans cet emplacement pour chaque concepteur, de sorte que l’emplacement peut contenir plusieurs copies identiques de chaque assemblage.

Un autre emplacement existe cependant où les assemblys peuvent être copiés et fait partie de la séquence de recherche de l’assembly, apparemment avant le dossier ProjectAssemblies et qui se trouve dans:

C: \ Program Files \ Microsoft Visual Studio 10.0 \ Common7 \ IDE

Je ne sais pas comment ni quand les assemblys sont copiés à cet emplacement, mais ce n’est pas souvent ainsi, quels fichiers arrivent ici deviennent rapidement une source de références obsolètes. Lorsqu’un concepteur échouait avec l’erreur «Impossible de charger le fichier ou l’assembly» , la version recherchée par le concepteur était une version uniquement référencée par l’assembly à cet emplacement.

Cela a été découvert en utilisant un deuxième débogage de l’instance Visual Studio sur le premier, avec tous les symboles .net chargés et toutes les exceptions connues au lancement, par opposition au non-géré. Cela a permis à la deuxième instance d’intercepter les exceptions de concepteur traitées et de révéler l’emplacement de ce fichier. C’était le résultat de l’erreur de conception que j’ai utilisée:

 === Pre-bind state information === LOG: User = ************** LOG: DisplayName = ***********, Version=1.0.4275.22699, Culture=neutral, PublicKeyToken=null (Fully-specified) LOG: Appbase = file:///C:/Program Files/Microsoft Visual Studio 10.0/Common7/IDE/ LOG: Initial PrivatePath = NULL Calling assembly : ***********, Version=1.0.4275.22699, Culture=neutral, PublicKeyToken=null. === LOG: This bind starts in default load context. LOG: Using application configuration file: C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.Config LOG: Using host configuration file: LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config. LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: The same bind was seen before, and was failed with hr = 0x80070002. 

Ce qui m’a aidé a été de supprimer TOUS les répertoires bin et obj pour tous les projets de la solution. Supprimez également les dossiers dans C: \ Users \\ AppData \ Local \ Microsoft \ VisualStudio \ 9.0 \ ProjectAssemblies, comme mentionné précédemment. Utilisez 9.0 pour VS2008, 10.0 pour VS2010 etc.

En utilisant VS 2005, j’ai rencontré ce même problème. J’ai effectué les étapes énumérées par Chien dans sa question initiale, mais cela n’a toujours pas fonctionné avant que je ferme VS et rouvert la solution. Maintenant, la vue du concepteur a l’air bien.

Je suppose que ce problème se produit pour différentes raisons, mais je pensais quand même partager mon cas. J’espère que quelqu’un trouvera un indice sur ce qui se passe avec leur projet.

Mon problème est survenu depuis que Visual Studio (projet C #) n’a pas pu trouver le dll c ++ géré et le copier à l’emplacement mentionné dans J Collins post => le concepteur n’a pas pu trouver le fichier. J’ai remarqué qu’il n’y avait pas de copie avec l’autre DLL: s et découvert qu’il y avait un répertoire de sortie différent / non standard. En changeant cela en standard, Visual Studio exécute la copie.

A été confronté à ce problème pendant quelques heures. Voici ce que j’ai appris: VÉRIFIEZ QUE LA DLL QUE LE DESIGNER ESSAYE DE CHARGER EST UNE DLL DE 64 BITS .

Il est évident que VS est une application 32 bits, donc le VS Designer – surprise! surprise! est également une application 32 bits, donc si vous avez un contrôle UserControl ou un autre contrôle WinForms ayant une référence à une DLL 64 bits, cela signifie que votre formulaire ne doit pas être rendu dans le concepteur VS et produire l’erreur can-not-load-file-or-assembly . Donc, la première chose à faire est de vous assurer que la DLL dont se plaint Designer n’est PAS une DLL 64 bits.

Il m’est arrivé très fréquemment sur VS2005, en particulier lors de l’ajout de contrôles personnalisés à la winform. En général, il me suffisait de reconstruire, sans avoir à append de références supplémentaires, ni de fermer et de rouvrir VS.

Il n’y a pas de cause apparente à cela, juste des bugs VS.

J’avais un problème similaire.

Dans mon cas, j’avais un formulaire de base, qui référençait une classe dans une DLL en mode mixte (wrapper managé c ++ vers une bibliothèque non managée). Mon formulaire dérivé ne s’est pas chargé correctement, donnant la même erreur que celle décrite ci-dessus.

Toutefois, le problème suivant a été résolu: http://support.microsoft.com/kb/967050

  1. Générez à la fois le projet en mode mixte et le projet d’interface utilisateur pour Win32. Puisque VS est 32 bits, il ne peut pas charger le code non géré x64:
  2. Effacer le dossier ProjectAssemblies (nécessite la fermeture de VS en premier)

Lorsque vous rouvrez VS, le concepteur charge sans problèmes. Notez que par défaut, les projets C # sont compilés en tant que CPU quelconque qui comstack en x64 sous Windows x64.

J’espère que cela aide quelqu’un.

J’ai eu ce problème dans un projet c ++ / cli.

Comme d’autres personnes l’ont mentionné, le Windows Form Designer instancie apparemment une version de votre Form / Usercontrol avant de le rendre.

Si le Concepteur de fiches ne peut pas instancier la classe pour une raison quelconque, elle échouera. Donc ce que j’ai fait a été de commenter le constructeur de l’Usercontrol fautif, et de reconstruire mon projet.

Cela m’a permis d’utiliser à nouveau le Concepteur de formulaires.

Bien entendu, vous pouvez utiliser cette méthode pour commenter de manière sélective des parties du constructeur jusqu’à identifier la partie qui fait chuter le Concepteur de fiches et, si possible, la corriger.

Je suis d’accord avec le commentaire Resharper. Je cours 4.1. Je l’ai désactivé, redémarrer VS2008 et essayé à nouveau le “Convertir en application Web”, et cela a fonctionné.

J’ai vu cela se produire dans VS2005 pour les projets Window Forms, ASP.NET et Compact Framework. Le projet que je construis a une dépendance sur un autre assemblage de ma solution, mais se plaint de ne pas pouvoir le charger lors de la génération du fichier de concepteur.

Je ne suis pas sûr de la cause exacte, mais cela arrive parfois après que nous ayons augmenté le numéro de version de l’assemblage. Pour une raison quelconque, Visual Studio ne verra pas cet assembly comme “nouveau” et ne supprimera pas la nouvelle version dans le dossier / bin du projet en cours. La plupart du temps, il le fait.

La suppression de la corbeille / du dossier (et du dossier obj / pour une bonne mesure) du projet avec l’erreur du concepteur, puis la reconstruction, semble faire disparaître le problème.

Je suis confronté au même problème. J’ai enlevé la référence du projet et ajouté à nouveau, et tout fonctionne bien (en regardant dans le fichier ptoject j’ai vu que la définition de référence a été modifiée, par exemple le tag “SpecificVersion” a été ajouté et défini sur “false”).

J’ai trouvé, avec des problèmes comme celui-ci, et bien d’autres, que le problème tourne autour de l’installation du framework .NET. Beaucoup de fois, comme lors d’un plantage du système, les fichiers peuvent être corrompus, notamment. si vous avez désactivé la mémoire virtuelle. Lorsque les fichiers du dossier C: \ WINDOWS \ Microsoft.NET sont corrompus, ils ne fonctionnent pas comme ils le devraient, car il y a beaucoup de ces fichiers, les erreurs ne se produisent pas toujours. Certaines parties d’un fichier peuvent être correctes et chargées, alors que d’autres ne le font pas. Au fil des ans, j’ai trouvé bon de conserver une sauvegarde complète du dossier Microsoft.NET dans une archive qui contenait un certain type de protection contre la corruption. Vous ne croiriez pas que le nombre d’éléments endommagés par les fichiers .NET est incorrect. Presque tous les aspects de l’EDI dépendent de certaines de ses parties, ainsi que de nombreuses autres fonctionnalités. Bien sûr, si vous n’avez pas de sauvegarde, vous DEVEZ DÉSINSTALLER TOUTES LES INSTALLATIONS NET FRAMEWORK (ne réparez pas car cela ne garantit pas la réécriture des fichiers – les fichiers peuvent passer des contrôles de sum de contrôle et de longueur mais sont toujours corrompus). Après la désinstallation, redémarrez le système, assurez-vous que l’intégralité du dossier Microsoft.NET est supprimé, sinon supprimez-le vous-même (je devais le faire, certains fichiers étaient toujours laissés de côté). Une fois cela fait, réinstallez le framework NET, en fonction de votre système d’exploitation, vous ne pourrez peut-être pas vous débarrasser de tout. Mais avec Windows XP, je sais que vous pouvez, je n’ai pas testé cela sur les nouveaux OS que vous êtes seul pour celui-là en ce qui concerne les tests. J’ai commencé par installer 2.0, puis 3.5 SP1, etc., en fonction de Visual Studio que vous utilisez. Je rest fidèle à 2008 parce que c’est le plus rapide pour moi et a toujours le support pour certains des nouveaux trucs comme WPF, tr1, etc. J’espère que cela vous aidera quelqu’un d’autre avec .NET woes, les messages d’erreur sont souvent trompeurs 99% du temps, c’est de la corruption de fichiers Microsoft.NET.

Pour toute personne qui a ce problème à l’avenir et qui la fait défiler jusqu’au bout: Supprimez ComponentModelCache dans Appdata / Local / Microsoft / VisualStudio / ..

J’ai fait face à ce problème plusieurs fois. La plupart du temps clean+rebuild fonctionne (parfois combiné avec le redémarrage de Visual Studio).

Deux fois quand clean+rebuild n’a pas fonctionné, c’était:

Numéro 1

Dans l’un des cas auxquels j’ai dû faire face, cela concernait C # et VB.NET.

J’ai eu plusieurs contrôles utilisateur dans mon formulaire qui ne se chargeait pas dans le concepteur. Les contrôles utilisateur étaient en C #. La plupart d’entre eux étaient sous le même espace de nom, mais peu d’entre eux avaient une partie de l’espace de nommage qui ne correspondait pas à l’alphabet.

Par exemple:

 userContorl1 was in myapp.mynamespace1, and userControl2 was in myapp.myNamespace1 

Pour C #, ils sont différents car C # est sensible à la casse. Mais VB.NET est insensible à la casse. L’erreur que j’ai eu était en essayant de charger myapp.mynamespace.userControl2. Après avoir lutté pendant longtemps, j’ai remarqué l’espace de noms dans le message d’erreur et corrigé dans le contrôle utilisateur, les rendant tous identiques à «myapp.myNamespace1», et le concepteur d’alto ouvert après clean+rebuild .

Numéro 2

Mon formulaire (qui ne s’ouvrait pas) comportait de nombreux contrôles utilisateur. L’un des contrôles était une propriété de type enum. Cette énumération a été définie dans une classe générique. Le code généré par le concepteur pour ce contrôle utilisateur était quelque chose comme:

 myUserControl1.SomeType = somenamespace.SomeGenericClass(of Date).SomeEnum 

L’erreur que j’ai eue en ouvrant designer, c’était comme:

Impossible de charger le type somenamespace.SomeGenericClass [System.Date] + SomeEnum

J’ai déplacé le code en dehors de la classe et remplacé le code du concepteur pour:

 myUserControl1.SomeType = somenamespace.SomeEnum 

Et le designer a ouvert 🙂

J’espère que cela aide quelqu’un.

Je dirai que les réponses dans ce fil de discussion m’ont quelque peu aidé, mais n’ont pas déterminé exactement ce qui se passait dans mes contrôles utilisateur personnalisés.

Dans mon cas particulier, j’ai de nombreuses bibliothèques de classes d’assistance qui effectuent des tâches telles que le style sur mes contrôles, la journalisation en arrière-plan et uniquement des classes d’assistance génériques qui exécutent des tâches courantes que je fais tout le temps.

J’utilisais certaines de ces autres méthodes statiques pour effectuer une journalisation en cas d’erreur. Voici un exemple:

try { _InitializeStuff(); } catch (Exception ex) { Logger.Instance.Log("Couldn't instantiate: " + ex.Messsage); }

Je l’ai fait dans les méthodes Constructor, Load et Property Set de mes contrôles utilisateur … et le concepteur ne pouvait pas toujours créer son chemin vers les appels de méthode statiques, ce qui entraînait l’échec du concepteur.

J’ai essayé de placer des vérifications de DesignMode autour de lui, mais le problème n’était pas au moment de l’exécution – c’était la conception et les liens ne pouvaient pas être construits. La seule option pour moi était de supprimer toutes les références à mes classes d’assistance statique dans les endroits suivants de mes contrôles utilisateur personnalisés:

  • Constructeur
  • Charge
  • Accessoires de propriété

Essayer de déboguer ceci avec un IDE secondaire et utiliser Attach to Process ne fonctionnait pas pour moi, malheureusement.

Assurez-vous également que vous avez une déclaration d’ utilisation de la bibliothèque avec le contrôle de votre formulaire ou contrôle. Une fois que le concepteur le connaît, il écrit l’espace de noms complet dans les références aux objects du fichier Form.designer.cs.

J’utilise VS2005 et VS2013 et j’ai vu le même problème. Certains concepteurs de formulaires Visual Studio de mon projet fonctionnent et d’autres ne s’ouvrent pas en mode conception. Certaines tentatives d’ouverture provoquent même le blocage de Visual Studio, avant l’apparition de la page d’erreur:

Pour éviter toute perte de données avant de charger le concepteur, les erreurs suivantes doivent être résolues:

Une remarque:
S’il y a des composants hérités dans le formulaire, le concepteur peut cesser de fonctionner

Un exemple de pseudo-code de l’observation:

 ... using System.Windows.Forms; // UserControl namespace MyNamespace { public class MyForm : Form { public MyForm() { InitializeComponent(); ... } private void InitializeComponent() { //this.ctrl = new MyNamespace.MyCtrl(); // Inherited class this.ctrl = new System.Windows.Forms.UserControl(); ... } //private MyNamespace.MyCtrl myCtrl; // Inherited class private UserControl ctrl; } public class MyCtrl : UserControl { ... } } 

Dans l’implémentation sans pseudo-code, j’ai commenté le composant hérité MyCtrl dans MyForm et utilisé la classe de base UserControl . Le Visual Studio Form Designer a recommencé à fonctionner!

La façon d’écrire un concepteur de formulaire Visual Studio correctement en interaction avec la classe de composant héritée en C # me dépasse. Mais, cette observation peut être un indice pour quelqu’un qui peut le résoudre.

J’ai essayé plusieurs des suggestions ci-dessus concernant la suppression de fichiers, la redéfinition, le redémarrage, etc. Mon problème était qu’il ne pouvait pas charger un assemblage d’utilitaire utilisé par quelques projets de la solution. Un autre projet avait des contrôles communs. Ainsi, Form1 référencé ControlsAssembly1 référencé UtilityAssembly1. Le fichier .resx avait des propriétés de types dans UtilityAssembly1. J’ai supprimé les ressources qui contenaient ces types. Essayé d’ouvrir à nouveau le formulaire (obtenu une exception de référence nulle en raison de la ressource manquante), appuyez sur Ignorer et continuer et mon problème a été résolu.

Pour obtenir votre retour Tout d’abord, allez à l’invite de commande de Visual studio 2008.

tapez devenv /resetsettings
tapez devenv /resetSkippkgs

  1. Dans l’explorateur de solutions, cliquez sur “Afficher tous les fichiers”
  2. Maintenant, ouvrez Form1.vb en double-cliquant, puis cliquez sur + pour le développer.
  3. Ouvrez Form1.Designer.vb
  4. vous pouvez voir les deux tabs dans votre fenêtre d’éditeur (IDE).
  5. Cliquez maintenant sur l’onglet “Form1.vb” et enregistrez-le.
  6. De même, cliquez avec le bouton droit sur l’onglet Form1.vb [Design] et enregistrez-le également.
  7. Reconstruisez votre projet.
  8. Redémarrez Visual Studio.

J’ai fait face à ce problème. J’ai fait ce qui est dit ci-dessus mais cela n’a aucun sens. Puis j’ai ajouté l’assemblage aux références. Reconstruire le projet. Fermé Visual Studio. Ensuite, rouvrir l’écran et le concepteur est apparu comme d’habitude.

Cordialement,