Communiqué de génération .fichiers pdb, pourquoi?

Parce que sans les fichiers PDB, il serait impossible pour déboguer une "Libération" de construire par rien d'autre que de l'adresse au niveau de débogage. Optimisations vraiment faire un certain nombre sur votre code, il est très difficile de trouver le coupable si quelque chose va mal (disons, une exception est levée). Même définition de points d'arrêt est extrêmement difficile, parce que les lignes de code source ne peut pas être mis en rapport l'un-à-un avec (ou même dans le même ordre que) le code assembleur généré. Fichiers PDB vous aider, vous et le débogueur, la création de débogage post-mortem nettement plus facile.

Vous faire remarquer que si votre logiciel est prêt pour la diffusion, vous devriez avoir fait tous vos débogage d'ici là. Alors que c'est 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 qu'en tournant optimisations (ils sont désactivés par défaut dans le "Debug" configuration) peut parfois causer des bogues subtils, à croire que vous n'auriez pas autrement attraper. Quand vous faites cela de débogage, vous aurez envie de l'APB symboles.

2. Clients rapportent souvent des cas limites et des bugs que seuls les cultures sous "idéal" conditions". Ce sont des choses qui sont presque impossibles à reproduire en laboratoire, car ils reposent sur des déjanté de configuration de l'ordinateur de l'utilisateur. Si elles sont particulièrement utiles clients, ils vont le rapport de l'exception qui a été levée et de vous fournir une trace de la pile. Ou ils vont même vous permettre d'emprunter de leur machine à déboguer votre logiciel à distance. Dans chacun de ces cas, vous voudrez les fichiers PDB pour vous aider.

3. Le profilage toujours être fait sur la "Libération" construit avec les optimisations activées. Et une fois de plus, les fichiers PDB sont pratiques, car ils permettent à la notice de montage est profilée pour être mappée à nouveau 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 la compilation.^* Si vous ne créez pas d'eux au cours de la construction, vous avez perdu votre occasion. Il ne fait pas de mal rien de les créer. Si vous ne voulez pas distribuer, il vous suffit de les omettre de votre binaires. Mais si vous décidez plus tard que vous le voulez, vous êtes hors de la chance. Préférable de les générer et de les archiver une copie, juste au cas où vous auriez besoin d'eux.

Si vous voulez vraiment mettre hors tension, c'est toujours une option. Dans votre projet de la fenêtre Propriétés, définissez l'option "Debug Info" option "aucun" pour toute configuration que vous souhaitez modifier.

Noter, cependant, que le "Debug" et "Release" configurations ne par défaut utiliser des paramètres différents pour émettre des informations de débogage. Vous voulez conserver ce réglage. Le "Debug Info" est réglé sur "full" pour une version Debug, ce qui signifie qu'en plus d'un fichier PDB, symboles de débogage de l'information est intégrée à l'assemblée. Vous bénéficiez également de symboles qui prennent en charge des fonctions sympas comme modifier et continuer. En mode Release, le "apb" seul option est sélectionnée, qui, comme son nom l'indique, comprend uniquement le fichier PDB, sans affecter le contenu de l'assemblée. Il n'est donc pas tout à fait aussi simple que la simple présence ou de l'absence de fichiers PDB dans votre /bin répertoire. Mais en supposant que vous utilisez le "apb seule" option, le fichier PDB de présence n'aura aucune incidence sur les performances d'exécution de votre code.

_{^* Comme Marc Sherman souligne dans un commentaire, aussi longtemps que votre code source n'a pas changé (ou vous pouvez récupérer le code d'origine à partir d'un système de contrôle de version), vous pouvez reconstruire et à 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 pour générer des binaires identiques à chaque fois que vous compilez le même code, donc il y peut des différences subtiles. Pire, si vous avez effectué des mises à niveau de votre chaîne de traitement dans l'intervalle (comme l'application d'un service pack pour Visual Studio), le Pdb sont encore moins susceptibles de correspondre. Pour garantir la fiabilité de la génération de ex postfacto fichiers PDB, vous devez archives non seulement le code source dans votre système de contrôle de version, mais aussi les fichiers binaires pour l'ensemble de votre construire ensemble des outils pour s'assurer que vous pourriez justement de recréer 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.}

Sans le .fichiers pdb, il est pratiquement impossible de l'étape à travers le code de production; vous devez compter sur d'autres outils qui peuvent être coûteux et prend du temps.
Je comprends que vous pouvez utiliser de traçage ou de windbg par exemple, mais cela dépend vraiment de ce que vous voulez atteindre.
Dans certains scénarios, vous voulez juste pour passer le code à distance (pas d'erreurs ou d'exceptions) à l'aide de la production de données pour observer le comportement particulier, et c'est là .fichiers pdb viennent à portée de main. Sans exécuter le débogueur sur que le code est impossible.

Aussi, vous pouvez utiliser les vidages sur incident pour le débogage de votre logiciel. Le client envoie vers vous, puis vous pouvez l'utiliser pour identifier la version exacte de votre source et de Visual Studio va même de tirer le bon ensemble de symboles de débogage (et la source si vous avez configuré correctement) en utilisant le fichier de vidage sur incident. Voir Microsoft la documentation sur le Symbole Magasins.

Dans un environnement multi-projet solution, généralement, vous voulez avoir une configuration qui ne génère aucun APB ou des fichiers XML à tous. Au lieu de changer la Debug Info propriété de chaque projet afin de none, j'ai pensé qu'il serait plus opportun d'ajouter un post-créer un événement qui ne fonctionne que dans une configuration spécifique.

Malheureusement, Visual Studio ne permet pas de spécifier les différents événements après génération, pour différentes configurations. J'ai donc décidé de le faire manuellement en éditant le csproj fichier de démarrage du projet et l'adjonction de ce qui suit (au lieu de tout PostBuildEvent tag):

  <PropertyGroup Condition="'$(Configuration)' == 'Publish'">
    <PostBuildEvent>
        del *.pdb
        del *.xml
    </PostBuildEvent>
  </PropertyGroup>

Malheureusement, cela va rendre l'événement post-construction zone de texte vide et de mettre quelque chose en elle peut donner des résultats imprévisibles.

Fait sans fichiers PDB et symbolique de l'information qu'ils ont, il serait impossible de créer avec succès un rapport de crash (fichiers de vidage de mémoire) et Microsoft n'aurait pas l'image complète de ce qui a causé le problème.

Et ainsi d'avoir APB améliore le rapport d'incident.