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


264

Pourquoi Visual Studio 2005 génère-t-il les .pdbfichiers lors de la compilation dans la version? Je ne déboguerai pas une version, alors pourquoi sont-elles générées?


18
Pourquoi générer pdb en version réelle? Ainsi, lorsqu'un rapport d'erreur vient de la nature, vous disposez d'informations pour le déboguer. L'autre valeur est que les clients peuvent le déboguer lorsque l'auteur d'origine ne le fera pas.
Ian Boyd

@IanBoyd: La deuxième phrase de ce commentaire implique que vous déployez les PDB. Dans la grande majorité des cas, cela n'est pas souhaitable.
IInspectable

3
@IInspectable Or is souhaitable
Ian Boyd

@IanBoyd: La grande majorité des cas n'inclut pas les déploiements de système d'exploitation. En outre, ces PDB ne contiennent pas de symboles privés, qui sont inclus par défaut lorsque vous générez des PDB.
IIspectable

@IInspectable D'un autre côté, la publication de PBD est souhaitable. Idéalement, oui, tout le monde écrirait du code compilé en IL, afin que nous puissions obtenir nous-mêmes les informations de symbole. Mais les compilateurs de code natif n'ont toujours pas de moyen facile de prendre en charge le débogage sur le terrain.
Ian Boyd

Réponses:


416

Parce que sans les fichiers PDB, il serait impossible de déboguer une build "Release" par autre chose que le débogage au niveau de l'adresse. Les optimisations font vraiment un certain nombre sur votre code, ce qui rend très difficile de trouver le coupable en cas de problème (disons, une exception est levée). Même la définition de points d'arrêt est extrêmement difficile, car les lignes de code source ne peuvent pas être mises en correspondance une à une avec (ou même dans le même ordre que) le code d'assembly généré. Les fichiers PDB vous aident, vous et le débogueur, à faciliter considérablement le débogage post mortem.

Vous faites valoir que si votre logiciel est prêt à être publié, vous devriez avoir effectué tout votre débogage d'ici là. Bien que cela soit certainement vrai, il y a quelques points importants à garder à l'esprit:

  1. Vous devez également tester et déboguer votre application (avant de la publier) à l'aide de la version "Release". En effet, l'activation des optimisations (elles sont désactivées par défaut dans la configuration "Debug") peut parfois provoquer des bogues subtils que vous n'auriez pas pu détecter autrement. Lorsque vous effectuez ce débogage, vous aurez besoin des symboles PDB.

  2. Les clients signalent fréquemment des cas marginaux et des bogues qui n'apparaissent que dans des conditions "idéales". Ce sont des choses qui sont presque impossibles à reproduire en laboratoire car elles reposent sur une configuration délirante de la machine de cet utilisateur. S'ils sont des clients particulièrement utiles, ils signaleront l'exception qui a été levé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 souhaiterez que les fichiers PDB vous aident.

  3. Le profilage doit toujours être effectué sur les versions "Release" avec les optimisations activées. Et encore une fois, les fichiers PDB sont utiles, car ils permettent de mapper les instructions d'assemblage profilées au code source que vous avez réellement écrit.

Vous ne pouvez pas revenir en arrière et générer les fichiers PDB après la compilation. * Si vous ne les créez pas pendant la construction, vous avez perdu votre chance. Cela ne fait rien de mal de les créer. Si vous ne souhaitez pas les distribuer, vous pouvez simplement les omettre de vos binaires. Mais si vous décidez plus tard de les vouloir, vous n'avez pas de chance. Mieux vaut toujours les générer et archiver une copie, juste au cas où vous en auriez besoin.

Si vous voulez vraiment les désactiver, c'est toujours une option. Dans la fenêtre Propriétés de votre projet, définissez l'option "Informations de débogage" sur "aucune" pour toute configuration que vous souhaitez modifier.

Prenez note, toutefois, que les configurations « Debug » et « Release » font par l' utilisation par défaut différents paramètres pour émettre des informations de débogage. Vous souhaiterez conserver ce paramètre. L'option "Informations de débogage" est définie sur "complet" pour une version de débogage, ce qui signifie qu'en plus d'un fichier PDB, les informations de symbole de débogage sont incorporées dans l'assembly. Vous obtenez également des symboles qui prennent en charge des fonctionnalités intéressantes telles que la modification et la poursuite. En mode Release, l'option "pdb-only" est sélectionnée, ce qui, comme cela sonne, inclut uniquement le fichier PDB, sans affecter le contenu de l'assemblage. Ce n'est donc pas aussi simple que la simple présence ou absence de fichiers PDB dans votre /binrépertoire. Mais en supposant que vous utilisez l'option "pdb-only", le fichier PDB '

* Comme le souligne Marc Sherman dans un commentaire , tant que votre code source n'a pas changé (ou que vous pouvez récupérer le code d'origine à partir d'un système de contrôle de version), vous pouvez le reconstruire et générer un fichier PDB correspondant. Du moins, généralement. 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 , il peut donc y avoir de subtiles différences. Pire, si vous avez effectué des mises à niveau de votre chaîne d'outils entre-temps (comme l'application d'un service pack pour Visual Studio), les PDB sont encore moins susceptibles de correspondre. Garantir la génération fiable d' ex postfactoFichiers PDB, vous devez archiver non seulement le code source dans votre système de contrôle de version, mais également les fichiers binaires de l'ensemble de votre chaîne d'outils de génération pour vous assurer que vous pouvez recréer avec précision la configuration de votre environnement de génération. Il va sans dire qu'il est beaucoup plus facile de créer et d'archiver simplement les fichiers PDB.


19
"Vous ne pouvez pas générer les fichiers PDB après la compilation." - Si votre code source n'a pas changé, vous pouvez reconstruire pour générer une PDB utilisable après coup. Par défaut, windbg ne chargera pas ce PDB mais vous pouvez le forcer à se charger en spécifiant l'option / i comme ceci .reload /i foo.dll. Cela chargera foo.pdb même si foo.pdb a été créé après la libération de foo.dll.
Marc Sherman

J'ai remarqué que chaque nouvelle compilation a un condensé de hachage différent, donc il y a de légères variations avec chaque build même dans le même environnement. Les adresses des PDB ne pourraient-elles pas changer avec variance, d'où la nécessité de conserver la PDB de cette version? Je ne fais que présenter cela comme une idée car je ne comprends pas vraiment comment fonctionnent les PDB ou pourquoi les hachages changent entre les builds.
thebunnyrules

1
@the Dans la note de bas de page, j'ai lié à un article expliquant que "le compilateur C # par conception ne produit jamais deux fois le même binaire. Le compilateur C # incorpore un GUID fraîchement généré dans chaque assembly, chaque fois que vous l'exécutez, garantissant ainsi qu'il n'y a pas deux assemblys sont toujours bit à bit identiques. " Cela explique pourquoi il a un hachage différent, et donc un fichier PDB différent. Ceci est réparable avec un éditeur hexadécimal, mais pas convivial. Et aussi en dehors de la portée de cette réponse.
Cody Gray

3
Il y a une nouvelle fonctionnalité dans Roslyn appelée builds déterministes. "L'indicateur / deterministic amène le compilateur à émettre exactement le même EXE / DLL, octet par octet, lorsqu'il reçoit les mêmes entrées." Cela signifie qu'un projet compilé à l'origine avec cet indicateur peut être recompilé exactement au même binaire, tant que le code que vous compilez est le même. Une explication plus longue peut être trouvée à Builds déterministes à Roslyn
K Smith

92

La PDB peut être générée Releaseaussi bien pour que pour Debug. Il est défini sur (dans VS2010 mais dans VS2005 doit être similaire):

Projet → Propriétés → Générer → Avancé → Informations de débogage

Changez-le simplement en None.


2
Mais pourquoi feriez-vous cela? Si votre logiciel est prêt pour la sortie, vous devriez avoir fait tout votre débogage d'ici là
m.edmondson

4
Parce que vous pouvez déboguer les problèmes de production. Une fois, nous devions le faire.
Aliostad

21
L'avantage de l'en-tête PDB pour le code de production est que .NET utilisera ces fichiers lors du lancement d'exceptions. Il génère des traces de pile avec des noms de fichiers et des numéros de ligne, ce qui est souvent très pratique!
Steven

6
@ m.edmondson: Oui, c'est exact. Vous serez toujours informé ce que l'exception levée était (comme FileNotFoundException), mais vous ne serez pas en mesure de voir une trace de la pile. Cela rend très difficile de déterminer exactement quelle ligne de code a provoqué la levée de l'exception.
Cody Gray

2
@ m.edmondson Juste pour ajouter si vous cherchez un outil pour déboguer à distance l'un des problèmes dans vos boîtes de production, le SDK Windows est livré avec un outil très célèbre appelé WinDbg qui prend en charge le débogage à distance. Veuillez consulter le lien mentionné ci-dessous. J'espère que cela t'aides! msdn.microsoft.com/en-in/library/windows/hardware/…
RBT

8

Sans les fichiers .pdb, il est pratiquement impossible de parcourir le code de production; vous devez compter sur d'autres outils qui peuvent être coûteux et longs. Je comprends que vous pouvez utiliser le traçage ou windbg par exemple, mais cela dépend vraiment de ce que vous voulez réaliser. Dans certains scénarios, vous souhaitez simplement parcourir le code à distance (sans erreur ni exception) en utilisant les données de production pour observer un comportement particulier, et c'est là que les fichiers .pdb sont utiles. Sans eux, exécuter le débogueur sur ce code est impossible.


7

Pourquoi êtes-vous si sûr de ne pas déboguer les versions de versions? Parfois (j'espère rarement mais arrive), vous pouvez obtenir un rapport de défaut d'un client qui n'est pas reproductible dans la version de débogage pour une raison quelconque (horaires différents, petit comportement différent ou autre). Si ce problème semble être reproductible dans la version, vous serez heureux d'avoir le pdb correspondant.


5
@ m.edmondson Accédez à la machine distante à l'aide de RDP, Webex, etc. et installez windbg à cet endroit. Configurez votre chemin de symboles et bam, vous êtes en or!
Marc Sherman

Un lien vers un guide plus détaillé aurait été plus utile. Ce mode d'emploi en ligne pourrait conduire les gens (comme moi) sur la mauvaise voie. La plupart des développeurs .NET ne savent rien de Windbg par exemple.
nuzzolilo

1
@ m.edmondson - Certaines éditions de Visual Studio ont la possibilité d'effectuer un débogage à distance. Dans le menu de débogage, vous "vous attachez au processus" sur la machine distante.
Matthew

Est-ce une si bonne idée de déboguer à distance une instance d'application de production? Cela ne brisera-t-il pas l'exécution parallèle des threads et les forcera-t-il à s'exécuter en série lors du débogage?
Kaveh Hadjari

4

Vous pouvez également utiliser des vidages sur incident pour déboguer votre logiciel. Le client vous l'envoie et vous pouvez ensuite l'utiliser pour identifier la version exacte de votre source - et Visual Studio tirera même le bon ensemble de symboles de débogage (et la source si vous êtes correctement configuré) à l'aide du vidage sur incident. Consultez la documentation de Microsoft sur les magasins de symboles .


2

Le fichier .PDB est le nom abrégé de "Program Database". Il contient les informations sur le point de débogage du débogueur et les ressources utilisées ou référencées. Son généré lorsque nous construisons en mode débogage. Son permet à l'application de déboguer au moment de l'exécution.

La taille est l'augmentation du fichier .PDB en mode débogage. Il est utilisé lorsque nous testons notre application.

Bon article du fichier pdb.

http://www.codeproject.com/Articles/37456/How-To-Inspect-the-Content-of-a-Program-Database-P


1
"Pas besoin de ce fichier lors de la publication ou du déploiement", sauf lorsque quelqu'un rencontre un crash dans cette version publiée et que le rapport de crash que vous obtenez ne contient pas de trace de pile utilisable ... alors vous souhaiterez l'inclure après tout.
Nyerguds le

Pas vrai. Sans les fichiers .pdb, vous obtiendrez une trace de pile complète, mais sans les noms des fichiers source. Vous pouvez le récupérer en interne après réception du rapport de plantage. Si vous vous souciez de vos droits intellectuels et que vous obscurcissez les sources, vous devez enregistrer les fichiers .pdb mais pas les déployer.
TOP KEK

1

Dans une solution multi-projets, vous souhaitez généralement avoir une configuration qui ne génère aucun fichier PDB ou XML. Au lieu de changer la Debug Infopropriété de chaque projet none, j'ai pensé qu'il serait plus judicieux d'ajouter un événement post-build qui ne fonctionne que dans une configuration spécifique.

Malheureusement, Visual Studio ne vous permet pas de spécifier différents événements post-génération pour différentes configurations. J'ai donc décidé de le faire manuellement, en modifiant le csprojfichier du projet de démarrage et en ajoutant ce qui suit (au lieu de toute PostBuildEventbalise existante ):

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

Malheureusement, cela rendra la zone de texte de l'événement post-construction vide et y mettre quoi que ce soit peut avoir des résultats imprévisibles.


4
Cela supprimera TOUS les *.xmlfichiers, soyez prudent.
Mariusz Jamro

0

Symboles de débogage ( .pdb) et doc XML ( .xml) représentent un pourcentage important de la taille totale et ne doivent pas faire partie du package de déploiement normal. Mais il devrait être possible d'y accéder au cas où ils seraient nécessaires.

Une approche possible: à la fin du processus de génération TFS, déplacez-les vers un artefact distinct.


-1

En fait, sans les fichiers PDB et les informations symboliques qu'ils possèdent, il serait impossible de créer un rapport de panne réussi (fichiers de vidage de mémoire) et Microsoft n'aurait pas l'image complète de la cause du problème.

Et donc avoir PDB améliore les rapports de plantage.


Mais que manquera-t-il exactement sans les fichiers .pdb?
TOP KEK

Vous ne pouvez pas générer les fichiers PDB après la compilation. Ainsi, chaque version du logiciel major.minor [.build [.revision]] aurait dû être enregistrée chez Microsoft afin de bien comprendre ce qui s'est passé, mais ce n'est pas tout.
prosti

Le compilateur n'est pas garanti de générer des binaires identiques chaque fois que vous compilez le même code.
prosti

La question était de savoir ce qui manquera dans les rapports de plantage et comment les rapports de plantage seront affectés. Les fichiers pdb .NET contiennent uniquement des noms de variables privées et des noms de fichiers source. Tout le reste (noms de méthodes, signatures, etc.) sera dans la trace de pile des informations de métadonnées.
TOP KEK

Aucun fichier PDB ne contient également de données non privées: github.com/microsoft/microsoft-pdb .
prosti
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.