Dans Visual Studio pour un projet C#, si vous allez dans Propriétés du projet > Compilation > Avancé > Informations de débogage, vous avez trois options : none, full ou pdb-only.
Quel paramètre est le plus approprié pour une version finale?
Alors, quelles sont les différences entre full et pdb-only?
Si j'utilise full, y aura-t-il des conséquences sur les performances? Si j'utilise pdb-only, sera-t-il plus difficile de résoudre les problèmes en production?
Je construirais avec pdb-only. Vous ne pourrez pas attacher un débogueur au produit libéré, mais si vous obtenez un crash dump, vous pouvez utiliser Visual Studio ou WinDBG pour examiner les traces de la pile et les dumps mémoire au moment du crash.
Si vous optez pour full plutôt que pdb-only, vous obtiendrez les mêmes avantages, sauf que l'exécutable pourra être attaché directement à un débogueur. Vous devrez déterminer si cela est raisonnable compte tenu de votre produit et de vos clients.
Assurez-vous de sauvegarder les fichiers PDB quelque part afin de pouvoir les référencer lorsqu'un rapport de crash arrivera. Si vous pouvez mettre en place un serveur de symboles pour stocker ces symboles de débogage, tant mieux.
Si vous choisissez de construire avec none, vous n'aurez aucun recours en cas de crash sur le terrain. Vous ne pourrez pas faire d'examen après coup du crash, ce qui pourrait sérieusement entraver votre capacité à résoudre le problème.
Une note sur les performances:
John Robbins et Eric Lippert ont tous deux écrit des billets de blog sur le drapeau /debug, et ils indiquent tous deux que ce paramètre n'a aucun impact sur les performances. Il existe un drapeau distinct /optimize qui dicte si le compilateur doit effectuer des optimisations.
Il n'est pas mentionné que le mode full impactera les performances et pourrait donc être trompeur.
Martin, es-tu sûr qu'il y a un impact sur les performances lors de l'utilisation de "full"? D'après ce que j'ai lu, l'interrupteur "/debug" n'a aucun impact sur les performances. Consultez mes modifications récentes pour quelques références.
:/ maintenant je suis encore plus confus. Il semble qu'il n'y ait aucune différence entre les 2 drapeaux selon ce drapeau (un article que j'ai maintenant lu au moins 4 fois). Par conséquent, bien qu'il n'y ait aucune mention de l'impact sur les performances (il semble juste), vous dites que faire "PDB-Only" ne vous permettra pas de vous attacher à un produit finalisé, mais si c'est la même chose que le débogage complet, alors vous devriez pouvoir le faire. Je vais retirer mon vote négatif, mais pouvez-vous clarifier?
ATTENTION MSDN documentation pour l'interrupteur /debug (Dans Visual Studio, il s'agit de Debug Info) semble être obsolète! Voici ce qu'il contient, ce qui est incorrect
Si vous utilisez /debug:tout, sachez qu'il y a un impact sur la vitesse et la taille du code JIT optimisé et un petit impact sur la qualité du code avec /debug:tout. Nous recommandons /debug:pdbonly ou aucun PDB pour générer du code de version.
Une différence entre /debug:pdbonly et /debug:tout est qu'avec /debug:tout le compilateur émet un
DebuggableAttribute, qui est utilisé pour indiquer au compilateur JIT que des informations de débogage sont disponibles.
Alors, qu'est-ce qui est vrai maintenant?
S'ils sont exactement les mêmes, pourquoi avons-nous ces options? John Robbins (dieu du débogage windows) a découvert qu'elles sont là pour des raisons historiques.
À l'époque de .NET 1.0, il y avait des différences, mais avec .NET 2.0 il n'y en a plus. Il semble que .NET 4.0 suivra le même schéma. Après vérification avec l'équipe de débogage CLR, il n'y a aucune différence du tout.
Ce qui contrôle si le JITter effectue une construction de débogage, c'est l'interrupteur /optimize. <…>
En fin de compte, vous voulez construire vos versions de publication avec /optimize+ et l'un des interrupteurs /debug pour pouvoir déboguer avec le code source.
puis il continue à le prouver.
Maintenant, l'optimisation fait partie d'un interrupteur séparé /optimize (dans Visual Studio, il est appelé Optimiser le code).
En bref, peu importe le réglage DebugInfo de pdb-only ou tout, nous aurons les mêmes résultats. La recommandation est d'éviter Aucun car cela vous priverait de la possibilité d'analyser les rapports d'erreurs des produits publiés ou d'attacher le débogueur.
Réponse fantastique! Mes propres recherches (en comparant les fichiers générés) montrent les mêmes résultats.
@rpattabi Pouvez-vous préciser la référence selon laquelle pdbonly et full sont identiques ? Nous sommes en 2019 et la documentation indique toujours qu'ils sont différents et que full entraînera une dégradation des performances. De plus, VS2019 crée un projet avec la configuration Release par défaut définie sur pdbonly.
@joe Il y a une discussion en bas de la documentation MSDN msdn.microsoft.com/fr-fr/library/8cw0bt21.aspx . Jetez-y un oeil. Un contributeur a pointé vers github.com/dotnet/roslyn/blob/master/docs/compilers/CSharp/… pour des informations à jour où pdbonly et full sont mentionnés comme étant identiques. (FYI. Je n'utilise plus Windows ni VS. Donc je ne suis plus ce qui s'y passe. Mais après vérification, les informations dans ma réponse sont toujours pertinentes et la documentation MSDN est toujours incorrecte.)
Vous voudrez seulement PDB, mais vous ne voudrez pas donner les fichiers PDB aux utilisateurs. Les avoir pour vous-même, aux côtés de vos binaires, vous donne la possibilité de charger des dumps de plantage dans un débogueur comme WinDbg et de voir où votre programme a réellement échoué. Cela peut être plutôt utile lorsque votre code plante sur une machine à laquelle vous n'avez pas accès.
Le débogage complet ajoute l'attribut [Debuggable] à votre code. Cela a un impact énorme sur la vitesse. Par exemple, certaines optimisations de boucle peuvent être désactivées pour faciliter le pas à pas. De plus, cela a un petit effet sur le processus JIT, car cela active le suivi.
Cela a du sens. Je ne distribue pas vraiment de DLL aux utilisateurs de toute façon - c'est une application ASP.NET. Mais pouvez-vous améliorer votre réponse et justifier pourquoi vous devriez opter pour "pdb-only" vs. "full"? Est-ce un problème de performance?
@jkohlhepp: J'aimerais ajouter cependant que le débogage des versions de production est un peu délicat car vous perdrez certaines informations (en raison de JIT). Presque toujours, vous ne pourrez pas voir les valeurs des arguments de méthode. Pour contourner cela, vous pouvez temporairement désactiver l'optimisation JIT en utilisant ce lien.
Merci blowdart, et merci Ilian Pinzon pour les informations supplémentaires. Je sais que vous ne pouvez pas obtenir de débogage parfait avec le code de version, mais avoir les PDBs est mieux que rien.
Je suis en train d'écrire un gestionnaire d'exception non géré et la trace de la pile inclut le numéro de ligne lorsque pdb-only est utilisé, sinon je n'obtiens que le nom de la sous-fonction lorsque je choisis Aucun.
Si je ne distribue pas le fichier .pdb, je n'obtiens pas le numéro de ligne dans la trace de la pile même avec la construction pdb-only.
Donc, je distribue (déploiement XCOPY sur un LAN) le pdb avec l'exe à partir de mon application VB.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Le pdb-only ou aucun, toujours pour les versions finales.
15 votes
@leppie Merci, mais je cherche une justification de cette position.
0 votes
Question liée : stackoverflow.com/questions/1270986/…
0 votes
C'est génial s'il n'y a pas d'impact sur les performances. Et en ce qui concerne l'impact sur la mémoire? Si je crée une instance de StackTrace et demande des informations sur les fichiers, elles doivent provenir des données de symboles pdb. Est-ce que tous les symboles sont chargés en mémoire au démarrage de l'application? Quelle est l'utilisation approximative de la mémoire pour cela? (par exemple, le surcoût en pourcentage par rapport à la taille du code.)