Partager via

Rendre une image plus facile à déboguer dans .NET

Remarque

Cet article est spécifique à .NET Framework. Elle ne s’applique pas aux implémentations plus récentes de .NET, notamment .NET 6 et versions ultérieures.

Lors de la compilation de code non managé, vous pouvez configurer une image exécutable pour le débogage en définissant des commutateurs IDE ou des options de ligne de commande. Par exemple, vous pouvez utiliser l’option de ligne de commande /Zi dans Visual C++ pour lui demander d’émettre des fichiers de symboles de débogage (extension de fichier .pdb). De même, l’option de ligne de commande /Od indique au compilateur de désactiver l’optimisation. Le code résultant s’exécute plus lentement, mais il est plus facile de déboguer, si cela est nécessaire.

Lors de la compilation du code managé .NET Framework, les compilateurs tels que Visual C++, Visual Basic et C# compilent leur programme source en langage intermédiaire commun (CIL). CIL est ensuite compilé par JIT, juste avant l’exécution, dans du code machine natif. Comme avec le code non managé, vous pouvez configurer une image exécutable pour le débogage en définissant des commutateurs IDE ou des options de ligne de commande. Vous pouvez également configurer la compilation JIT pour le débogage de la même façon.

Cette configuration JIT a deux aspects :

  • Vous pouvez demander au compilateur JIT de générer des informations de suivi. Cela permet au débogueur de correspondre à une chaîne de code CIL avec son équivalent de code machine et de suivre l’emplacement des variables locales et des arguments de fonction stockés. Dans .NET Framework version 2.0 et ultérieure, le compilateur JIT génère toujours des informations de suivi. Il n’est donc pas nécessaire de le demander.

  • Vous pouvez demander au compilateur JIT de ne pas optimiser le code de l’ordinateur résultant.

Normalement, le compilateur qui génère le fichier CIL définit ces options de compilateur JIT de manière appropriée, en fonction des commutateurs IDE ou des options de ligne de commande que vous spécifiez, par exemple /Od.

Dans certains cas, vous souhaiterez peut-être modifier le comportement du compilateur JIT afin que le code de l’ordinateur qu’il génère soit plus facile à déboguer. Par exemple, vous pouvez générer des informations de suivi JIT pour une version commerciale ou pour l’optimisation du contrôle. Vous pouvez le faire avec un fichier d’initialisation (.ini).

Par exemple, si l’assembly que vous souhaitez déboguer est appelé MyApp.exe, vous pouvez créer un fichier texte nommé MyApp.ini, dans le même dossier que MyApp.exe, qui contient ces trois lignes :

[.NET Framework Debugging Control]
GenerateTrackingInfo=1
AllowOptimize=0

Vous pouvez définir la valeur de chaque option sur 0 ou 1, et toute option absente est définie par défaut sur 0. Régler GenerateTrackingInfo à 1 et AllowOptimize à 0 est la solution la plus simple pour le débogage.

À compter de .NET Framework 2.0, le compilateur JIT génère toujours des informations de suivi indépendamment de la valeur pour GenerateTrackingInfo; toutefois, la AllowOptimize valeur a toujours un effet. Lorsque vous utilisez le Ngen.exe (Générateur d’images natives) pour précompiler l’image native sans optimisation, le fichier .ini doit être présent dans le dossier cible avec AllowOptimize=0 quand Ngen.exe s’exécute. Si vous avez précompilé un assembly sans optimisation, vous devez supprimer le code précompilé à l’aide de NGen.exe option /uninstall avant de réexécuter Ngen.exe pour précompiler le code comme optimisé. Si le fichier .ini n’est pas présent dans le dossier, par défaut, Ngen.exe précompile le code comme optimisé.

System.Diagnostics.DebuggableAttribute contrôle les paramètres d’un assemblage. DebuggableAttribute inclut deux champs qui contrôlent si le compilateur JIT doit optimiser et/ou générer des informations de suivi. Dans .NET Framework 2.0 et versions ultérieures, le compilateur JIT génère toujours des informations de suivi.

Pour une build commerciale, les compilateurs ne définissent aucun DebuggableAttribute. Par défaut, le compilateur JIT génère les performances les plus élevées, les plus difficiles à déboguer le code de l’ordinateur. L’activation du suivi JIT réduit les performances un peu, et la désactivation de l’optimisation réduit beaucoup les performances.

S’applique à un assemblage entier à la fois, et non pas à des modules individuels au sein de l’assemblage. Les outils de développement doivent donc attacher des attributs personnalisés au jeton de métadonnées d’assembly, si un assembly a déjà été créé ou à la classe appelée System.Runtime.CompilerServices.AssemblyAttributesGoHere. L’outil ALink promeut ensuite ces DebuggableAttribute attributs de chaque module vers l’assembly dont ils font partie. En cas de conflit, l’opération ALink échoue.

Remarque

Dans la version 1.0 du .NET Framework, le compilateur Microsoft Visual C++ ajoute le DebuggableAttribute moment où les options du compilateur /clr et /Zi sont spécifiées. Dans la version 1.1 du .NET Framework, vous devez soit ajouter DebuggableAttribute manuellement dans votre code, soit utiliser l'option du compilateur /ASSEMBLYDEBUG.

Voir aussi

  • Last updated on