2009-05-04 16 views
10

Je parle de code .NET géré. Si nous exécutons un programme et y attachons VS, nous pouvons voir les valeurs des paramètres pour chaque méthode dans la pile d'appels. Je voudrais créer une solution de journalisation qui enregistrera toutes les valeurs de paramètres pour chaque méthode dans la pile d'appel. En fait, j'ai besoin de cette information en cas d'exception.Est-il possible d'obtenir les valeurs des paramètres pour chaque trame dans la pile d'appel dans .NET?

Je sais que c'est possible avec l'API de profilage. Mais je me demande est-ce possible avec seulement du code managé?

MISE À JOUR: Ok, probablement avec .NET net c'est impossible. Alors peut-être avec une sorte de code non géré ... le point est de le faire à partir de l'application elle-même. Une application en cas d'exception peut appeler une bibliothèque (peut-être non gérée) qui renvoie des informations sur les valeurs des méthodes dans la pile d'appels. Juste pensées ...

+1

Notez que les optimisations, en particulier en mode « Release », inline, etc., peuvent rendre l'information de ne pas apparaître dans la pile d'appels. Vous devriez mieux ne pas compter sur ce genre d'information. – Lucero

+1

Bien sûr, la logique de l'application ne devrait pas compter sur ces informations. Mais je parle juste de l'enregistrement à des fins de diagnostic. – Shrike

+0

Je l'ai compris. Cependant, si vous obtenez un extrait de journal et que vous ne disposez pas d'informations fiables, son utilité est limitée. – Lucero

Répondre

8

Les valeurs des paramètres ne sont pas stockées dans l'occurrence de StackFrame. En fait, ils ne sont pas enregistrés/enregistrés, sauf si vous choisissez de le faire explicitement.

Une façon évidente de consigner ces valeurs est d'utiliser AOP. Cela impliquerait certainement un coût, mais en conjonction avec un cadre de journalisation et le bon niveau de journalisation, cela pourrait être une alternative. Vous pouvez également choisir de n'instruire que certains types/méthodes dans votre code de base, où les exceptions sont plus susceptibles d'être levées. Je choisirais probablement Postsharp pour ses capacités de tissage statique, pour émettre des appels de journal.

Quoi qu'il en soit, il est loin d'être une solution idéale, mais je crains que vous n'aurez pas beaucoup d'options si vous êtes coincé dans le monde géré.

2

Votre meilleure option est probablement d'insérer le code de suivi requis dans les méthodes pertinentes. De cette façon, vous pouvez attacher des écouteurs de trace et vider des valeurs si nécessaire.

je sais que ce n'est pas ce que vous demandez, mais il est un moyen d'obtenir les données.

Vous pouvez déboguer l'application en utilisant WinDbg. Les commandes! Clstack /! Dso vous permettront d'inspecter les paramètres et les objets de la pile.