Libération de la génération.fichiers pdb, pourquoi?

parce que sans les fichiers PDB, il serait impossible de déboguer une compilation "Release" par autre chose que du débogage au niveau de l'adresse. optimisations font vraiment un nombre sur votre code, ce qui rend très difficile de trouver le coupable si quelque chose va mal (par exemple, une exception est lancée). Même le réglage des points de rupture est extrêmement difficile, parce que les lignes de code source ne peuvent pas être appariées un à un avec (ou même dans le même ordre que) le code d'assemblage généré. APB les fichiers vous aident ainsi que le débogueur, ce qui rend le déboguage post-mortem beaucoup plus facile.

Vous faites le point si votre logiciel est prêt pour la diffusion, vous devriez avoir fait tous vos débogage. Bien que cela soit certainement vrai, il y a quelques points importants à garder à l'esprit:

1. Vous devriez aussi tester et déboguer votre application (avant la libération) à l'aide de la "Libération" de construire. C'est parce que le fait d'activer les optimisations (elles sont désactivées par défaut dans la configuration "Debug") peut parfois faire apparaître des bugs subtils que vous n'auriez pas pu attraper autrement. Quand vous faites ce débogage, vous voulez les symboles de PDB.

2. les clients signalent fréquemment des cas de bordures et des bogues qui ne apparaissent que dans des conditions "idéales". Ce sont des choses qui sont presque impossibles à reproduire en laboratoire parce qu'elles reposent sur une configuration que l'ordinateur de l'utilisateur. S'ils sont particulièrement utiles, ils signaleront l'exception qui a été lancée et vous fourniront une trace de pile. Ou ils vous laisseront même emprunter leur machine pour déboguer votre logiciel à distance. Dans l'un ou l'autre de ces cas, vous aurez besoin des fichiers PDB pour vous aider.

3. Profilage toujours être fait sur la "Libération" construit avec les optimisations activées. Et encore une fois, les fichiers PDB sont utiles, parce qu'ils permettent aux instructions d'assemblage qui sont profilées d'être mappées vers le code source que vous avez réellement écrit.

Vous ne pouvez pas revenir en arrière et de générer les fichiers PDB après le compiler. ^* si vous ne les créez pas pendant la construction, vous avez perdu votre opportunité. Il ne fait pas de mal rien de les créer. Si vous ne voulez pas les distribuer, vous pouvez simplement les omettre de vos binaires. Mais si vous décidez plus tard que vous les Voulez, vous n'avez pas de chance. il est préférable de toujours les générer et archiver une copie, juste au cas où vous en auriez besoin.

si vous voulez vraiment les éteindre, c'est toujours une option. Dans la fenêtre Propriétés de votre projet, définissez l'option "Debug Info" à "none" pour toute configuration que vous voulez modifier.

notez, cependant, que le "Debug" et "Release" configurations faire par par défaut, utilisez différents paramètres pour l'émission des informations de débogage. Vous voudrez garder ce cadre. L'option" Debug Info "est définie à" full " pour une construction de débogage, ce qui signifie qu'en plus d'un fichier PDB, les informations du symbole de débogage sont intégrées dans l'assemblage. Vous obtenez également des symboles qui supportent des fonctionnalités cool comme edit-and-continue. En mode Release, l'option" pdb-only " est sélectionnée, qui, comme on le dirait, n'inclut que le fichier PDB, sans affecter le contenu de l'Assemblée. Il n'est donc pas aussi simple que la simple présence ou absence de fichiers PDB dans votre répertoire /bin . Mais en supposant que vous utilisiez l'option "pdb-only", la présence du fichier PDB n'affectera en aucune façon les performances d'exécution de votre code.

_{^* comme Marc Sherman le souligne dans un commentaire , tant que votre code source n'a pas changé (ou que vous pouvez récupérer le code original à partir d'un système de contrôle de version), vous pouvez le reconstruire et de générer un correspondant de fichier PDB. Au moins, en général. Cela fonctionne bien la plupart du temps , mais le compilateur n'est pas garanti de générer des binaires identiques chaque fois que vous compilez le même code , donc il peut être des différences subtiles. Pire, si vous avez fait des mises à jour à votre chaîne d'outils entre-temps (comme appliquer un service pack pour Visual Studio), Les PDB sont encore moins susceptibles de correspondre. Pour garantir la production fiable de ex postfacto fichiers PDB, vous aurez besoin d'archiver non seulement le code source dans votre système de contrôle de version, mais aussi les binaires pour l'ensemble de votre chaîne d'outils de construction pour vous assurer que vous pouvez recréer avec précision la configuration de votre environnement de construction. Il va sans dire qu'il est beaucoup plus facile de simplement créer et archiver les fichiers PDB.}