Mauvais numéros de ligne dans la trace de pile (release)

Question

Nous recevons parfois des traces de pile de notre client avec des numéros de ligne incorrects. Cela n'arrive pas si souvent, mais parfois cela nous énerve.

Les clients disposent d'assemblys de version avec optimisations et avec "pdb uniquement". informations de débogage.

Et oui, nous comparons les numéros de ligne avec exactement la même version de code que le client.

Et oui, le client a les bons fichiers pdb.

Et non, cette différence entre les numéros de ligne ne peut pas être expliquée avec la méthode inlining (optimisation du compilateur).

Et non, nous n'utilisons aucun outil AOP, comme PostSharp.

Des idées pourquoi cela se produit-il?

Answer 1

Ce n'est pas un expert .net, mais au moins dans d'autres langages, lorsque des optimisations élevées du compilateur sont choisies, le compilateur peut effectuer une réorganisation importante du code. Cela peut souvent rendre très difficile d'identifier la source d'une erreur sur une ligne donnée. Si le compilateur est capable d’optimiser les blocs de base, cet effet peut être très important, en plaçant l’emplacement de ligne apparent dans une partie totalement différente du fichier source.

Answer 2

Si vous utilisez beaucoup d'optimisation de compilation, le compilateur pourrait déplacer des parties de votre code, je suppose.

Le meilleur moyen de déboguer consiste à utiliser Reflector sur la dll utilisée par votre client. En utilisant les numéros de ligne du stacktrace, vous trouverez exactement quelles lignes de codes sont appelées lorsque l'application se bloque.