Concepteur de formulaires Windows: impossible de charger le fichier ou l'assembly
Quelqu'un a-t-il déjà eu le problème où essayer de "View Designer" sur un formulaire Windows dans Visual Studio .NET provoque l'erreur: "Impossible de charger le fichier ou l'assembly ..."?
Dans ce cas, l'Assemblée 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'elles) et reconstruire toute la solution. Cependant, après cela, j'ai supprimé toutes ces références de mon projet, reconstruit et cela a toujours fonctionné.
Une autre information est que j'utilise Resharper 2.5. Quelqu'un d'autre a fait remarquer que Resharper pourrait effectuer des clichés instantanés. J'examinerai cela la prochaine fois que cela se produira. Quelqu'un comprend-il pourquoi cette erreur se produit en premier lieu et peut-être la manière "correcte" de la corriger?
Nous avons le même problème. Certaines classes Form/UserControl ne peuvent pas être affichées dans Designer et Visual Studio provoque diverses exceptions.
Il existe une cause typique: l'un des composants conçus a levé une exception non gérée lors de l'initialisation (dans le constructeur ou dans l'é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 -> Déboguer -> Attacher au processus ... -> sélectionner une instance du processus devenv.exe avec le concepteur problématique. Appuyez ensuite sur Ctrl + Alt + E, les fenêtres "Exceptions" devraient s'afficher. Cochez "Lancé" dans les catégories d'exception.
Maintenant actif le studio visuel avec le concepteur et essayez le concepteur de vues. Si l'exception est levée, vous verrez la pile d'appels (et peut-être le code source, si l'exception a été levée à partir de votre code) et d'autres informations typiques sur l'exception levée. Ces informations peuvent être très utiles.
C'est une vieille question qui semble toujours sans réponse, ici ou dans le pool de forums plus large, la plupart des conseils concernent le nettoyage implacable> reconstruit ou ferme> nettoyer les dossiers> rouvrir ou redémarrer la machine. Je n'ai pas de réponse solide à l'heure actuelle, bien que j'aie fait des recherches à ce sujet et pensé que je pourrais partager. En résumé, il existe un emplacement dans lequel tous les fichiers du concepteur sont copiés lorsqu'un contrôle ou un formulaire est conçu, un autre emplacement dans lequel les anciens fichiers peuvent exister et une méthode est décrite pour intercepter toutes les exceptions du concepteur avant que le concepteur puisse générer la page d'erreur.
Il semble y avoir deux cas où un assembly ne peut pas être chargé ou introuvable. Le premier est dû au fait que les fichiers ne parviennent pas à copier vers les emplacements requis par le concepteur, le second est les fichiers obsolètes laissés pour compte.
Comme mentionné ci-dessus, les fichiers peuvent ne pas réussir à copier lorsqu'un projet ne fait pas directement référence à toutes les références requises 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 dépendants, en veillant à ce que toutes soient prises 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]\Local Settings\Application Data\Microsoft\VisualStudio\10.0\ProjectAssemblies
Windows 7:
C:\Users\[nom_utilisateur]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies
À cet emplacement, les assemblys compilés sont copiés dans dynamiquement les dossiers créés, un dossier par assembly. En vérifiant les dates de version de l'assembly à cet endroit, il semble être assez à jour, étant supprimé à la sortie de Visual Studio. Tous les assemblys sont copiés lorsqu'un concepteur est affiché avec des fichiers nouvellement compilés. Une nouvelle copie de chaque assemblage est créée à 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 des assemblys, 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 assemblages sont copiés vers cet emplacement, mais ce n'est pas souvent si les fichiers qui arrivent ici deviennent rapidement une source de références obsolètes. Lorsqu'un concepteur a échoué avec l'erreur 'Impossible de charger le fichier ou l'assembly' , la version recherchée par le concepteur était une version référencée uniquement par l'assembly à ce stade. emplacement.
Cela a été découvert en utilisant un deuxième débogage d'instance Visual Studio sur le premier, avec tous les symboles .net chargés, et toutes les exceptions connues se brisant lors de la levée par opposition à lorsqu'elles ne sont pas gérées. Cela a permis à la deuxième instance d'intercepter les exceptions du concepteur gérées et de révéler cet emplacement de fichier. Ce fut la sortie résultante de l'erreur du concepteur 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é, c'est la suppression de 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 d'origine, mais cela n'a toujours pas fonctionné jusqu'à ce que je ferme VS et rouvre la solution. Maintenant, la vue Designer semble bien.
A été aux prises avec ce problème pendant quelques heures. Voici ce que j'ai appris: VÉRIFIEZ SI LE DLL LE DESIGNER IS ESSAYEZ DE CHARGER IS A 64- BIT DLL.
Il s'avère, eh bien, évident pour moi maintenant, VS est une application 32 bits, donc VS Designer - surprise! surprise! est également une application 32 bits, donc si vous avez un UserControl ou un autre contrôle WinForms qui a une référence à un 64-BIT DLL - THAT IS UN GRAND NON-NON qui empêchera votre formulaire de s'afficher dans VS Designer et produira l'erreur impossible de charger le fichier ou l'assemblage. La première chose à faire est donc de vous assurer que le DLL dont le concepteur se plaint est PAS une DLL 64 bits.
Je suppose que ce problème se produit pour différentes raisons, mais j'ai pensé partager mon cas de toute façon. J'espère que quelqu'un trouvera un indice sur ce qui se passe avec son projet.
Mon problème est survenu car Visual Studio (projet C #) n'a pas pu trouver la DLL gérée c ++ et la copier à l'emplacement mentionné dans l'article J Collins => le concepteur n'a pas pu trouver le fichier. J'ai remarqué qu'il n'y avait pas été copié avec les autres DLL: et j'ai découvert qu'il avait un répertoire de sortie différent/non standard. La modification de ce dernier au standard fait Visual Studio effectuer la copie.
J'avais un problème similaire.
Dans mon cas, j'avais un formulaire de base, qui faisait référence à une classe dans une DLL en mode mixte (wrapper géré c ++ vers une bibliothèque non managée). Mon formulaire dérivé ne s'est pas chargé correctement, donnant la même erreur décrite ci-dessus.
Cependant, ce qui suit a résolu le problème: http://support.Microsoft.com/kb/96705
- Générez à la fois le projet en mode mixte et le projet d'interface utilisateur pour Win32. Étant donné que VS est 32 bits, il ne peut pas charger de code non géré x64:
- Effacez le dossier ProjectAssemblies (il faut d'abord fermer VS)
Lorsque vous rouvrez VS, le concepteur se charge sans problème. Notez que par défaut, les projets C # sont compilés en tant que CPU qui se compile en x64 sous Windows x64.
J'espère que cela aide quelqu'un.
Cela m'est arrivé très fréquemment sur VS2005, spécialement lors de l'ajout de contrôles personnalisés à la forme de victoire. Habituellement, je devais simplement reconstruire, sans avoir besoin d'ajouter des références supplémentaires, ni de fermer et de rouvrir VS.
Il n'y a aucune cause apparente à cela, juste des bogues VS.
J'ai eu ce problème dans un projet c ++/cli.
Comme d'autres personnes l'ont mentionné, apparemment, le Concepteur de formulaires Windows instancie une version de votre formulaire/utilisateur avant de le rendre.
Si le Concepteur de formulaires ne peut pas instancier la classe pour une raison quelconque, il échouera. J'ai donc commenté le constructeur du Usercontrol incriminé et reconstruit mon projet.
Cela m'a permis d'utiliser à nouveau le Concepteur de fiches.
Bien sûr, vous pouvez utiliser cette méthode pour commenter de manière sélective des parties du constructeur jusqu'à identifier la partie qui fait s'étouffer le Concepteur de fiches et, si possible, la corriger.
Assurez-vous également que vous disposez d'une déclaration en utilisant pour la bibliothèque avec le contrôle dans votre formulaire ou contrôle. Une fois que le concepteur en a connaissance, il écrit l'espace de noms complet en référence aux objets dans le fichier Form.designer.cs.
Je suis confronté au même problème. J'ai supprimé 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 la référence a été modifiée, par exemple, la balise "SpecificVersion" a été ajoutée et définie sur "false").
Afin de récupérer votre From. Tout d'abord, allez à l'invite de commande de Visual studio 2008.
tapez devenv /resetsettings
tapez devenv /resetSkippkgs
- Dans l'Explorateur de solutions, cliquez sur "Afficher tous les fichiers"
- Ouvrez maintenant Form1.vb en double-cliquant, puis cliquez sur + pour le développer.
- Ouvrez Form1.Designer.vb
- vous pouvez voir les deux onglets dans votre fenêtre d'éditeur (IDE).
- Maintenant, cliquez avec le bouton droit sur "Form1.vb" et enregistrez-le
- De même, cliquez avec le bouton droit sur l'onglet Form1.vb [Design] et enregistrez-le également
- Reconstruisez votre projet.
- Redémarrez Visual Studio.
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, en particulier. si la mémoire virtuelle est désactivée. 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 se charger, d'autres non. Au fil des ans, j'ai trouvé que le fait de conserver une sauvegarde COMPLÈTE du dossier Microsoft.NET dans une archive contenant un certain type de protection contre la corruption me convenait parfaitement. Vous ne croiriez pas le nombre de choses qui peuvent endommager les fichiers .NET corrompus. À peu près tous les aspects de IDE dépend de certaines parties de celui-ci ainsi que de nombreuses autres fonctionnalités. Bien sûr, si vous n'avez pas de sauvegarde, vous devez DÉSINSTALLER TOUTES LES INSTALLATIONS DU CADRE NET (ne pas réparer car cela ne garantit pas la réécriture des fichiers - les fichiers peuvent passer la vérification de la somme de contrôle et de la longueur mais être corrompus). Après la désinstallation, redémarrez le système, assurez-vous que le dossier Microsoft.NET entier est supprimé, sinon, supprimez-le vous-même (j'avais pour ce faire, certains fichiers sont laissés pour compte.) 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 cela. Mais avec windows XP Je sais que vous pouvez, je n'ai pas testé cela sur les nouveaux systèmes d'exploitation vous-même pour celui-ci en ce qui concerne les tests. J'ai commencé par installer 2.0, puis 3.5 SP1, et ainsi de suite, en fonction de Visual Studio que vous êtes Je m'en tiens à 2008 car c'est le plus rapide pour moi et j'ai toujours un support pour certaines des nouveautés comme WPF, tr1, etc ... s vous aide quelqu'un d'autre avec des problèmes .NET, les messages d'erreur sont souvent trompeurs mais pour moi 99% du temps, c'est une corruption de fichiers Microsoft.NET.
J'ai rencontré ce problème à plusieurs reprises. 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 que j'ai rencontrés, cela avait à voir avec C # et VB.NET.
J'avais 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 noms, mais peu d'entre eux avaient une partie de l'espace de noms qui ne correspondait pas dans le cas alphabétique.
Par exemple:
userContorl1 was in myapp.mynamespace1, and
userControl2 was in myapp.myNamespace1
Pour C #, ce sont des espaces de noms différents car C # est sensible à la casse. Mais VB.NET n'est pas sensible à la casse. L'erreur que j'ai eue était lors du chargement de 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 s'est ouvert après clean+rebuild.
Numéro 2
Mon formulaire (qui ne s'ouvrait pas), comportait de nombreux contrôles utilisateur. L'un des témoins avait une propriété de type enum. Cette énumération a été définie dans une classe générique. Le concepteur a généré du code pour ce contrôle utilisateur était quelque chose comme:
myUserControl1.SomeType = somenamespace.SomeGenericClass(of Date).SomeEnum
L'erreur que j'ai eue lors de l'ouverture du concepteur était la suivante:
n'a pas pu charger le type somenamespace.SomeGenericClass [System.Date] + SomeEnum
J'ai déplacé l'énumération en dehors de la classe et remplacé le code du concepteur par:
myUserControl1.SomeType = somenamespace.SomeEnum
Et le designer a ouvert. :)
J'espère que cela aide quelqu'un.
J'utilise VS2005 et VS2013 et j'ai vu le même problème. Certains concepteurs de formulaires Visual Studio dans mon travail de projet et d'autres ne s'ouvrent pas en mode conception. Certaines tentatives d'ouverture font même planter Visual Studio, avant que la page d'erreur n'apparaisse, en disant:
Pour éviter une éventuelle perte de données avant de charger le concepteur, les erreurs suivantes doivent être résolues:
Une remarque:
S'il existe 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 non pseudo-code, j'ai commenté le composant hérité MyCtrl dans MyForm, et j'ai utilisé à la place la classe de base UserControl. Visual Studio Form Designer a recommencé à fonctionner!
Comment écrire correctement Visual Studio Form Designer -interagir, classe de composant héritée en C # me dépasse. Mais, cette observation pourrait être un indice pour quelqu'un, qui peut le résoudre.
J'ai fait face à ce problème. J'ai fait ce qui est dit ci-dessus mais cela n'avait aucun sens. J'ai ensuite ajouté l'Assemblée aux références. Reconstruisez le projet. Fermez Visual Studio. Rouvrez ensuite l'écran et le concepteur est apparu comme normal.
Cordialement,
Juste pour carillon là-dessus. Je construis une nouvelle version de mon UserControl alors que mon autre projet était ouvert et le référençant. Lorsque je suis retourné voir le concepteur dans le formulaire référençant le contrôle utilisateur, il a dit qu'il ne pouvait pas trouver le fichier .dll d'une version spécifique.
J'ai essayé de supprimer la référence au contrôle et à la boîte à outils, sans succès. Le code se compilerait très bien, mais le concepteur ne s'afficherait pas sans l'erreur.
J'ai essayé tout ce qui précède et cela n'a pas fonctionné.
Le fichier .res du formulaire contient du XML:
<data name="EventBar1.EventCheckedSubscriptions" mimetype="application/x-Microsoft.net.object.binary.base64">
<value>
AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
</value>
</data>
<data name="EventBar1.EventLengthSubscriptions" mimetype="application/x-Microsoft.net.object.binary.base64">
<value>
AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
</value>
</data>
<data name="EventBar1.EventLengthTypes" mimetype="application/x-Microsoft.net.object.binary.base64">
<value>
AAEAAAD/////AQAAAAAAAAAMAgAAAKABY3RybENhbGVuZGFyU2lkZUJhciwgVmVyc2lvbj0xLjAuNzEy
MS4yMTIzNCwgQ3VsdHVyZT1uZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1udWxsXV0sIG1zY29ybGliLCBW
ZXJzaW9uPTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0
ZTA4OQwDAAAAUWN0cmxDYWxlbmRhclNpZGVCYXIsIFZlcnNpb249MS4wLjcxMjEuMjEyMzQsIEN1bHR1
cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49bnVsbAUBAAAAT1N5c3RlbS5Db2xsZWN0aW9ucy5HZW5l
cmljLkxpc3RgMVtbY3RybENhbGVuZGFyU2lkZUJhci5FdmVudEJhcitFdmVudExlbmd0aFR5cGUDAAAA
Bl9pdGVtcwVfc2l6ZQhfdmVyc2lvbgQAAC5jdHJsQ2FsZW5kYXJTaWRlQmFyLkV2ZW50QmFyK0V2ZW50
TGVuZ3RoVHlwZVtdAwAAAAgIAgAAAAkEAAAAAAAAAAAAAAAHBAAAAAABAAAAAAAAAAQsY3RybENhbGVu
ZGFyU2lkZUJhci5FdmVudEJhcitFdmVudExlbmd0aFR5cGUDAAAACw==
</value>
</data>
<data name="EventBar1.EventSettingsSubscriptions" mimetype="application/x-Microsoft.net.object.binary.base64">
<value>
AAEAAAD/////AQAAAAAAAAAMAgAAAJoBbXNjb3JsaWIsIFZlcnNpb249NC4wLjAuMCwgQ3VsdHVyZT1u
ZXV0cmFsLCBQdWJsaWNLZXlUb2tlbj1iNzdhNWM1NjE5MzRlMDg5XV0sIG1zY29ybGliLCBWZXJzaW9u
PTQuMC4wLjAsIEN1bHR1cmU9bmV1dHJhbCwgUHVibGljS2V5VG9rZW49Yjc3YTVjNTYxOTM0ZTA4OQUB
AAAANlN5c3RlbS5Db2xsZWN0aW9ucy5HZW5lcmljLkxpc3RgMVtbU3lzdGVtLkV2ZW50SGFuZGxlcgMA
AAAGX2l0ZW1zBV9zaXplCF92ZXJzaW9uAwAAFVN5c3RlbS5FdmVudEhhbmRsZXJbXQgIAgAAAAkDAAAA
AAAAAAAAAAAHAwAAAAABAAAAAAAAAAMTU3lzdGVtLkV2ZW50SGFuZGxlcgs=
</value>
</data>
J'ai supprimé cela du fichier .res et tout va bien. J'ai sauvegardé tout le dossier avant d'essayer!
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 assembly dans ma solution, mais se plaint qu'il ne peut pas le charger lorsque vous essayez de générer le fichier de concepteur.
Je ne suis pas sûr de la cause exacte, mais cela se produira parfois après avoir augmenté le numéro de version de l'Assemblée. Pour une raison quelconque, Visual Studio ne verra pas cet assembly comme "nouveau" et ne déposera pas la nouvelle version dans le dossier/dossier du projet actuel. Mais la plupart du temps, c'est le cas.
La suppression du dossier bin/(et le dossier obj/pour faire bonne mesure) du projet avec l'erreur du concepteur, puis la reconstruction, semblent faire disparaître la blessure.
Je dirai que les réponses dans ce fil m'ont un peu aidé, mais n'ont pas exactement précisé 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 seulement des classes d'assistance génériques qui effectuent des tâches de routine que je fais tout le temps.
J'utilisais certaines de ces autres méthodes de bibliothèque statiques pour effectuer la journalisation en cas d'erreur. Voici un exemple:
try { _InitializeStuff(); } catch (Exception ex) { Logger.Instance.Log("Couldn't instantiate: " + ex.Messsage); }
J'ai fait cela dans les méthodes Constructor, Load et Property Set de mes contrôles utilisateur ... et le concepteur ne pouvait pas toujours construire son chemin vers les appels de méthode statique, donc le concepteur échouerait.
J'ai essayé de placer des contrôles DesignMode autour de lui, mais le problème n'était pas au moment de l'exécution - c'était au moment de la conception et les liens n'ont pas pu être créés. La seule option pour moi était de supprimer toutes les références à mes classes d'assistance statiques dans les emplacements suivants de mes contrôles utilisateur personnalisés:
- Constructeur
- Charge
- Accesseurs de propriété
Essayer de déboguer ceci avec un secondaire IDE et utiliser Attach to Process n'a pas travaillé pour moi, malheureusement.
À tous ceux qui ont ce problème à l'avenir et qui ont fait défiler la page vers le bas pour le rechercher: Supprimer ComponentModelCache dans Appdata/Local/Microsoft/VisualStudio/..
J'ai essayé bon nombre des suggestions ci-dessus concernant la suppression de fichiers, le réaménagement, le redémarrage, etc. Mon problème était qu'il ne pouvait pas charger un assemblage utilitaire utilisé par quelques projets dans 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. J'ai essayé d'ouvrir à nouveau le formulaire (obtenu l'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.