visual-studio - vsdesigner - tentative de chargement d'un programme de format incorrect 0x8007000b




Concepteur de formulaires Windows: Impossible de charger le fichier ou l'assemblage (14)

Est-ce que quelqu'un a 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'assemblage ..." ?

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 n'en dépend pas directement) et en reconstruisant la solution entière. Cependant, après cela, j'ai supprimé toutes les références de mon projet, reconstruit, et cela fonctionnait encore.

Une autre information est que j'utilise Resharper 2.5 . Quelqu'un d'autre a fait remarquer que Resharper pourrait faire des copies d'ombre. Je vais regarder dans la prochaine fois que cela arrive. Est-ce que quelqu'un a une idée de la raison pour laquelle cette erreur se produit en premier lieu, et peut-être la façon «correcte» de la réparer?


Cela m'est arrivé très souvent sur VS2005, spécialement lors de l'ajout de contrôles personnalisés au winform. Habituellement, je devais simplement reconstruire, sans avoir besoin d'ajouter des références supplémentaires, ou fermer et rouvrir VS.

Il n'y a pas de cause apparente pour cela, juste des bugs VS.


En utilisant VS 2005, j'ai rencontré ce même problème. J'ai exécuté les étapes énumérées par Chien dans sa question initiale, mais cela n'a pas fonctionné jusqu'à ce que j'ai fermé VS et ai rouvert la solution. Maintenant, la vue Designer a l'air bien.


J'ai vu cela se produire dans VS2005 pour les projets Windows 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 en essayant de générer le fichier du concepteur.

Je ne suis pas sûr de la cause exacte, mais cela arrive parfois après que nous avons augmenté le numéro de version de l'assemblage. Pour une raison quelconque, Visual Studio ne verra pas cet assembly comme étant «nouveau» et ne supprimera pas la nouvelle version dans le dossier / bin du projet en cours. La plupart du temps c'est le cas.

Suppression du bin / dossier (et l'obj / dossier pour faire bonne mesure) du projet avec l'erreur de concepteur, puis la reconstruction, semble faire disparaître la douleur.


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é changée, par exemple "SpecificVersion" tag a été ajouté et mis à "false").


J'ai trouvé, avec des problèmes comme celui-ci, et beaucoup d'autres, le problème tend à tourner autour de l'installation du framework .NET. Beaucoup de fois, comme lors d'un crash du système, les fichiers peuvent être corrompus esp. si vous avez désactivé la mémoire virtuelle. Lorsque les fichiers dans le dossier C: \ WINDOWS \ Microsoft.NET sont endommagés, 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 ok et charger, alors que d'autres ne le font pas. Au fil des années, j'ai trouvé que conserver une sauvegarde complète du dossier Microsoft.NET dans une archive qui a un certain type de protection contre la corruption fonctionne bien pour moi. Vous ne croiriez pas le nombre de choses que les fichiers .NET corrompus peuvent causer. À peu près tous les aspects de l'EDI dépendent 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 INSTALLER TOUTES LES INSTALLATIONS EN CADRES NETTES (ne pas réparer car cela ne garantit pas que les fichiers sont réécrits - les fichiers peuvent passer la somme de contrôle mais être corrompus). Après la désinstallation, redémarrez le système, assurez-vous que l'ensemble du dossier Microsoft.NET est supprimé, sinon, supprimez-le vous-même (je devais le faire, certains fichiers sont toujours laissés pour compte). Une fois cela fait, réinstallez le framework NET, en fonction de votre système d'exploitation, vous pourriez ne pas être en mesure de se débarrasser de l'ensemble. Mais avec Windows XP je sais que vous pouvez, je n'ai pas testé cela sur les systèmes d'exploitation plus récents que vous êtes seul pour celui-ci en ce qui concerne les tests. J'ai commencé par installer 2.0, puis 3.5 SP1, et ainsi de suite, selon quel Visual Studio vous utilisez. Je m'en tiens à 2008 parce que c'est le plus rapide pour moi et il a toujours le support pour certaines choses plus récentes comme WPF, tr1, etc ... j'espère que cela vous aidera à quelqu'un d'autre avec les malheurs .NET, les messages d'erreur sont souvent trompeurs 99% du temps c'est la corruption de fichiers Microsoft.NET.


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


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

Comme d'autres personnes l'ont mentionné, le Concepteur de formulaires Windows 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, il échouera. Donc ce que j'ai fait était de commenter le constructeur du Usercontrol incriminé, et de reconstruire mon projet.

Cela m'a permis d'utiliser à nouveau le concepteur de formulaires.

Bien sûr, vous pouvez utiliser cette méthode pour commenter sélectivement des parties du constructeur jusqu'à ce que vous identifiiez la partie qui étouffe le concepteur de formulaires et, si possible, corrigez-le.


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: l'une des exceptions non gérées de composants conçus lors de l'initialisation (dans le constructeur ou dans l'événement Load ou avant).

Non seulement pour ce cas, vous pouvez exécuter une autre instance de Visual Studio, ouvrir / créer un projet indépendant, aller au menu -> Déboguer -> Attacher au processus ... -> Sélectionner l'instance du processus devenv.exe avec concepteur problématique. Puis appuyez sur Ctrl + Alt + E , les fenêtres "Exceptions" doivent être affichées. Là cocher "Thrown" dans les catégories d'exception.

Maintenant actif le studio visuel avec le concepteur et essayent le concepteur de vue. Si l'exception est levée, vous verrez callstack (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. Cette information peut être très utile.


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 que j'ai affronté, il avait à voir avec C # et VB.NET.

J'ai eu plusieurs contrôles d'utilisateur dans mon formulaire qui ne 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 l'alphabet-cas.

Par exemple:

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

Pour C #, ils sont différents espaces de noms car C # est sensible à la casse. Mais VB.NET est insensible à la casse. L'erreur que j'ai eu était lors de la tentative de 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 de l'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), avait de nombreux contrôles utilisateur. Un des contrôles était d'avoir une propriété de type enum. Cette énumération a été définie à l'intérieur d'une classe générique. Le code généré par le concepteur pour ce contrôle d'utilisateur était quelque chose comme:

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

L'erreur que j'ai eu lors de l'ouverture du concepteur, était comme:

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

J'ai déplacé l'enum à l'extérieur de la classe et remplacé le code du concepteur par:

myUserControl1.SomeType = somenamespace.SomeEnum

Et le concepteur a ouvert. :)

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


Je dirai que les réponses dans ce fil m'a aidé un peu, mais n'a pas exactement cloué ce qui se produisait dans mes contrôles utilisateur personnalisés.

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

J'utilisais certaines de ces autres méthodes statiques de bibliothèque pour effectuer la 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 construire son chemin vers les appels de méthodes statiques, donc le concepteur échouait.

J'ai essayé de placer des vérifications de DesignMode autour d'elle, mais le problème n'était pas au moment de l'exécution - c'était au moment du design, et les liens n'ont pas pu être construits. La seule option pour moi était de supprimer toutes les références à mes classes auxiliaires statiques dans les endroits suivants de mes contrôles utilisateur personnalisés:

  • Constructeur
  • Charge
  • Accesseurs de propriété

Essayer de déboguer ceci avec un IDE secondaire et utiliser Attach to Process n'a pas fonctionné pour moi, malheureusement.


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


J'utilise VS2005 et VS2013 et vu le même problème. Certains concepteurs de formulaires Visual Studio dans mon travail de projet et d'autres ne s'ouvriront pas en mode Création. Certaines tentatives d'ouverture font même planter Visual Studio, avant que la page d'erreur n'apparaisse, disant:

Pour éviter toute 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 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 utilisé à la place la classe de base UserControl . Le concepteur de formulaires Visual Studio a recommencé à fonctionner!

Comment écrire correctement un Concepteur de formulaires Visual Studio - interagir, la classe de composant héritée en C # est au-delà de moi. Mais, cette observation pourrait être un indice pour quelqu'un, qui peut s'en sortir.


Afin d'obtenir votre retour. Tout d'abord, allez à Visual Studio 2008 invite de commande.

type devenv /resetsettings
type devenv /resetSkippkgs

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

Je suppose que ce problème se produit pour différentes raisons, mais je pensais partager mon cas de toute façon. J'espère que quelqu'un trouvera une idée de ce qui se passe dans leur projet.

Mon problème s'est produit puisque Visual Studio (projet C #) n'a pas pu trouver la DLL c ++ gérée et la copier à l'endroit mentionné dans J Collins post => le concepteur n'a pas pu trouver le fichier. J'ai remarqué qu'il n'était pas copié là avec les autres DLL: s et a découvert qu'il avait un répertoire de sortie différent / non-standard. Changer cela à la norme faite Visual Studio effectuer la copie.





windows-forms-designer