Échec du chargement de l'élément de la boîte à outils. Il sera supprimé de la boîte à outils
J'ai une application WinForm. J'ai aussi créé mon propre User Control pour cela. Tout a bien fonctionné. Jusqu'à aujourd'hui, j'ai reçu le message d'erreur lorsque j'essaie de le rajouter à mon programme (je ne l'ai jamais supprimé. Visual Studio l'a fait).
Échec du chargement de l'élément de la boîte à outils #UserControlName. Il sera supprimé de la boîte à outils.
Je l'ai dans l'explorateur de solutions, mais il disparaît de ma boîte à outils après cette erreur. Je reçois également l'avertissement qui dit:
'#UserControlName' n'est jamais affecté à et aura toujours sa valeur par défaut Null.
Et quand je regarde mon code de concepteur, c'est vrai. Mais je n'ai rien fait avec mon code de designer. Mon contrôle utilisateur est défini ici mais pas instancié. Comment puis-je le remettre?
Cela at-il quelque chose à voir avec le fait que j'ai changé ma plate-forme de génération de x32 à x64? Si tel est le cas, je serai surpris car le programme fonctionnait bien après ce changement.
Dans de tels moments, vous serez obligé de bricoler avec le code du concepteur. Tant que vous n'apportez pas de modifications radicales au code du concepteur, vous ne devez rien casser. Pour être sûr de jouer, ré-instancier l'objet où les autres contrôles sont instanciés (près du haut de la page). Le concepteur doit remplir les blancs pour les propriétés et autres.
Cela devrait également renvoyer le contrôle à la boîte à outils.
Je souffrais du même problème pour l'une de nos applications et je ne pouvais pas trouver de solution. J'ai donc créé manuellement les contrôles utilisateur et personnalisé. Après une nouvelle recherche sur le Web, j'ai enfin trouvé pourquoi le concepteur échouait pour ce projet particulier. La réponse est que le projet est en 64 bits et que Visual Studio n’a toujours pas de version 64 bits, il est toujours en 32 bits. Le concepteur n'a donc pas pu charger les contrôles dans les applications 64 bits ou dans les bibliothèques de classes. Lisez l'article de Microsoft à ce sujet. Un article sur le site Web de Visual Studio a été supprimé. Voir la réponse dans le forum de support Visual Studio.
J'ai eu le même problème récemment. Comme cela (ni aucune autre réponse sur ce site et sur Internet) ne m'aidait réellement, j'ai trouvé le moyen de le réparer.
Il suffit de nettoyer les fichiers et de reconstruire la solution. Aussi simple que cela.
Vous n'êtes pas obligé d'insérer manuellement le contrôle utilisateur. J'ai eu la même situation et il y avait une raison pour cela.
Dans mon cas, cela a échoué parce que l'assembly EXE a été compilé en «mode mixte» à l'aide du type de support CLR /clr. Après l'avoir changé en "géré uniquement" en définissant le type /clr:pure, cela a fonctionné.
Pour plus de détails, voir ma réponse ici à SO .
Après de nombreuses heures de réflexion avec ce problème avec un contrôle personnalisé volumineux avec peu de modifications par rapport à une copie de travail précédente dans le contrôle de code source, j'ai copié tout le code dans un nouveau nom et fichier de contrôle et tout fonctionnait.
Cela visait à identifier la ou les lignes de code qui posaient problème, car le débogueur ne coopérerait pas. Le contrôle copié (ainsi que des tas de code et de modules de support) fonctionnait correctement.
Donc, ce sont les étapes très simples qui ont corrigé mon code original
- En solution Explorer renommer le fichier (je viens d'ajouter un s à la fin)
- Reconstruire
- Tester le contrôle peut maintenant être ajouté à une forme simple
- Renommez le contrôle à son nom d'origine
L'étape 4 pourrait être facultative pour vous, mais si vous avez le contrôle de source et que c'est dans une bibliothèque, vous voudrez le faire.
Cela a ramené le contrôle sur tous mes formulaires qui ne fonctionnaient pas (pour autant que je sache). Il semble que le problème se trouve dans VS qui se souvient qu’il n’aime pas ça?
J'espère que cela aide et j'espère trouver ce message la prochaine fois que je l'aurai quand j'aurai oublié le correctif :)
P.S. Nettoyer, reconstruire et/ou réexécuter la solution est l'ancienne solution à ce problème, mais cette fois, il ne s'agissait que d'un contrôle personnalisé dans une classe entière (DLL). J'espère que cela t'aides.
Pour moi, après avoir ajouté le contrôle utilisateur, je reconstruis d'abord l'application, puis j'ai actualisé les éléments de la boîte à outils en accédant à projets => actualiser les éléments de la boîte à outils du projet.
Passez à AnyCPU et reconstruisez le projet. Visual Studio rencontre des problèmes de contrôle 64 bits.
Vérifiez dans votre fichier form.designer s'il existe une propriété laissée de ce type. Cela m'est arrivé plusieurs fois. Après avoir supprimé cette ligne et reconstruit le projet, tout a commencé à fonctionner.