Afficher le nombre de lignes dans le Stack Trace pour l'assemblage .NET en mode Release

Question

Existe-t-il un moyen d'afficher les lignes dans la trace de la pile pour l'assemblage .NET construit/déployé en mode Release ?

UPDATE :

Mon application est divisée en trois projets de bibliothèque de classes et un projet de "site Web" ASP.NET. L'erreur que j'essaie de déceler se trouve dans l'un des trois projets de bibliothèque de classes. J'ai seulement déployé le fichier pdb pour le projet de bibliothèque de classes qui génère l'erreur "Object reference not set to an instance of an object".

Les numéros de ligne n'apparaissent toujours pas dans la trace de la pile. Dois-je déployer les fichiers pdb pour tous les projets afin d'obtenir les numéros de ligne dans le suivi de pile ?

Solution de travail

Le déploiement du fichier pdb pour chaque application a résolu le problème du numéro de ligne.

Answer 1

• Allez dans la fenêtre des propriétés du projet où vous voulez voir les numéros de ligne de la trace de la pile.
• Cliquez sur le bâtiment "onglet vertical".
• Sélectionnez la configuration "Release". Vérifiez le paramètre constant DEBUG.
• Décochez le paramètre "Optimiser le code" pour éviter le problème occasionnel de trace avec le code inlined (cette étape n'est pas essentielle).
• Appuyez sur le bouton Advanced... et choisissez Output -> Debug Info -> pdb-only.
• Déployez le fichier .pdb généré avec l'assemblage.

Answer 2

Dans VS2012, vous devez également décocher la case "Exclure les symboles de débogage générés" dans la section Package/Publish Web des propriétés.

Answer 3

Ma solution

Copiez le fichier pdb dans le même dossier que le fichier exécutable.

maintenant je peux voir le numéro de ligne quand je lance le fichier exe.

c'est la raison

http://msdn.microsoft.com/en-us/library/ee416588%28v=vs.85%29.aspx

Answer 4

J'ai rencontré des problèmes dans le passé où j'ai ressenti le besoin de déployer des fichiers PDB avec un build de version afin de traquer une erreur. La raison en est, comme vous l'avez dit, que l'exception se produisait dans une méthode de très grande taille et que je ne pouvais pas déterminer avec précision où elle se produisait.

Cela peut indiquer que la méthode doit être refactorisée en méthodes plus petites et plus granulaires. Il n'y a pas de réponse universelle, mais cette approche m'a bien servi à court terme (j'ai souvent trouvé le bogue pendant le remaniement) et à long terme.

Juste une idée.

Answer 5

Inclure les symboles de débogage avec votre paquetage de construction/déploiement.