Bonne façon de déboguer les erreurs Visual Studio Designer

Question

Existe-t-il un bon moyen de déboguer les erreurs dans Visual Studio Designer?

Dans notre projet, nous avons des tonnes de UserControls et de nombreuses formes complexes. Pour les plus complexes, le Designer jette souvent diverses exceptions qui n'aident pas beaucoup, et je me demandais s'il y avait une bonne façon de comprendre ce qui ne va pas.

Le langage est C#, et nous utilisons Visual Studio 2005.

Answer 1

Voir Debugging Design-Time Controls (MSDN).

Answer 2

Chacun est différent et ils peuvent parfois être obscur. Dans un premier temps, je ferais ce qui suit:

• Utilisez le contrôle de code source et sauvez souvent. Lorsqu'une erreur de concepteur se produit, obtenez une liste de tous les changements aux contrôles affectés qui se sont produits récemment et testez chacun jusqu'à ce que vous trouviez le coupable
• Assurez-vous de vérifier les routines d'initialisation des contrôles impliqués. Très souvent ces erreurs se produiront à cause d'une erreur ou d'une mauvaise dépendance qui est appelée via le constructeur par défaut pour un contrôle (une erreur qui peut se manifester uniquement dans VS)

Answer 3

Je l'ai fait se produire plusieurs fois et il est une vraie douleur. Premièrement, je suggérerais de tenter de suivre la trace de la pile fournie par le concepteur, bien que je trouve que souvent, il suffit de simplement énumérer un tas de choses internes qui ne sont pas très utiles.

Si cela ne fonctionne pas, essayez de compiler et de déterminer l'exception à partir de là. Tu es vraiment aveugle, quel est le problème. Vous pourriez alors essayer simplement d'exécuter le code et voir quelle exception est levée quand vous l'exécutez, cela devrait vous donner plus d'informations. Une approche de dernier souffle pourrait être d'enlever tout le code non généré du formulaire et de le réintroduire progressivement pour déterminer l'erreur.

Si vous utilisez des contrôles personnalisés, vous pouvez également supprimer manuellement le code généré relatif aux contrôles personnalisés si la méthode précédente génère toujours une erreur. Vous pouvez ensuite réintroduire cette étape étape par étape de la même manière pour déterminer quel contrôle personnalisé est à l'origine du problème, puis allez le déboguer séparément.

Fondamentalement, pour autant que je sache, il n'y a pas d'autre moyen de contourner le problème que de s'en sortir un peu!

Answer 4

J'ai été capable de déboguer certains problèmes de concepteur de contrôle en exécutant une seconde instance de VS, puis de votre première instance VS faire un "Debug -> Attach to Process" et choisir "devenv".

La première instance VS est l'endroit où vous définirez vos points d'arrêt. Utilisez la seconde instance pour charger le concepteur afin que le code "concepteur" s'exécute.

Answer 5

Vous pouvez exécuter une seconde instance de VS et l'attacher à la première instance de VS (Ctrl + Alt + P). Dans le premier cas, définissez les points d'arrêt, dans le second cas, exécutez le concepteur et le point d'arrêt se déclenchera. Vous pouvez parcourir le code, mais Modifier-et-Continuer ne fonctionnera pas. Pour que Edit-and-Continue fonctionne, définissez les options de débogage de la bibliothèque pour exécuter une VS avec l'argument de ligne de commande étant le nom de fichier de la solution.Ensuite, vous pouvez simplement définir les points d'arrêt et appuyez sur F5. Il va déboguer comme le code utilisateur! En guise de note, vous pouvez le faire VS et Office compléments également.

Answer 6

J'ai découvert pourquoi parfois les points d'arrêt ne sont pas touchés. Dans le dialogue Attach to Process, le type "Attach to:" doit être "Select ..." 'd.

Une fois que j'ai changé pour "Managed 4.0, 4.5", les points d'arrêt pour une application WinRT ont été touchés. Source: Designer Debugging in WinRT.

Answer 7

Cela a été une douleur en 2005 et c'est toujours en 2015. Les points d'arrêt ne seront souvent pas touchés, probablement à cause des assemblages qui sont copiés par l'ombre ou quelque chose de la part du concepteur (?). Le mieux que vous pouvez faire est de casser manuellement en introduisant un appel à Debugger.Break(). Vous pouvez envelopper dans un compilateur conditionnel comme tel:

#if DEBUG 
    System.Diagnostics.Debugger.Break(); 
#endif 
int line_to = break; // <- if a simple breakpoint here does not suffice