Traçage

 

Rob Howard
Microsoft Corporation

25 janvier 2001

Chaque fois que je donne une présentation sur ASP.NET, il est toujours amusant de watch le public lorsque la nouvelle fonctionnalité de traçage est démontrée. Pour ceux d’entre nous qui ont créé des solutions avec ASP, le traçage est une au dieu !

Dans la colonne de ce mois-ci, nous allons examiner la fonctionnalité de traçage dans ASP.NET. Commençons par discuter de la technique de traçage courante pour ASP, Response.Write().

Suivi avec ASP

Si vous êtes comme moi, lorsque vous codez une application ASP, vous utilisez des instructions Response.Write() lorsque vous disséquer une section problématique du code.

Voici quelques pseudo-codes pour illustrer ce point :

<%
On Error Resume Next 
Response.Write("About to do data access...")
Set objDB = Server.CreateObject("Custom.DataAccess")
objDB.Open("PersonalizationData")
user = objDB.Get("username")
Response.Write("Done calling data access. Value of username is:" + user)
%>

Les appels Response.Write() dans le code ci-dessus doivent être familiers, c’est-à-dire que nous avons une erreur avec le comportement de notre code. L’erreur n’est pas nécessairement une erreur d’application ou de système, telle qu’une erreur de chargement de l’objet, mais plutôt une erreur de codage dans laquelle le code s’exécute comme prévu, mais ne retourne pas la valeur attendue.

Bien sûr, nous pouvons également utiliser un débogueur, mais il est parfois juste plus rapide d’obtenir une sortie de trace pour savoir ce que fait le code ou simplement pour nous faire savoir comment une section particulière du code est exécutée.

Bien que les instructions Repsonse.Write() facilitent le débogage de l’application assez rapidement, elles introduisent du code inutile dans une application qui peut entraîner des bogues réels qui interrompent les applications déployées. Par exemple, il n’est généralement pas considéré comme une bonne chose quand nous oublions de supprimer une instruction Response.Write() plus colorée qui peut exprimer nos sentiments réels concernant le code sur lequel nous travaillons.

Bien sûr, la même fonctionnalité des instructions Response.Write() est prise en charge dans ASP.NET. En fait, je me retrouve toujours à utiliser Response.Write(), même si nous avons maintenant une fonctionnalité de traçage. Les vieilles habitudes sont difficiles à briser.

Cependant, nous devrions tous essayer de briser ces anciennes habitudes, car la nouvelle fonctionnalité de traçage nous donne quelque chose qui n’existait pas en mode ASP: debug.

Suivi avec ASP.NET

Les nouvelles fonctionnalités de suivi de ASP.NET nous permettent de simuler des instructions Response.Write(), mais pas de supprimer les instructions avant de déployer nos applications. Imaginez plutôt écrire le même code que ci-dessus, mais au lieu d’utiliser Response.Write(), nous utilisons Trace.Write().

L’objet Trace est désormais un objet de page intrinsèque, similaire à Request, Response, Server, etc. Il est accessible directement avec notre code de page.

Examinons brièvement la classe Trace .

Trace (classe)

La trace est exposée en tant que propriété publique dans ASP.NET pages. Lorsque nous utilisons la propriété Trace, nous travaillons avec un instance de la classe TraceContext définie dans l’espace de noms System.Web.

La classe Trace expose deux méthodes surchargées et deux propriétés. Les deux méthodes, Warn() et Write(), toutes deux prennent en charge deux prototypes identiques :

VB.NET

Public Sub [Warn | Write](category As String, 
                          message As String, 
                          errorInfo As Exception)
End Sub
Public Sub [Warn | Write](category As String, 
                          message As String)
End Sub

C#

public void [Warn | Write](String category, 
                           String message, 
                           Exception errorInfo)
public void [Warn | Write](String category, 
                           String message)

Le paramètre category est utilisé pour identifier le nom de catégorie dans lequel écrire la valeur du message . Cela devient plus évident lorsque nous utilisons la méthode Write() dans un exemple ci-dessous. Le troisième paramètre pris en charge par Warn() et Write() dans leurs méthodes surchargées est errorInfo. Cela nous permet de transmettre les détails des exceptions dans le système de suivi.

Propriétés

La classe TraceContext prend en charge deux propriétés publiques : IsEnabled et TraceMode.

• IsEnabled indique si le suivi est activé sur la page ou pour l’application.
• TraceMode définit ou retourne le mode de tri utilisé par le suivi. Nous examinerons la configuration du mode trace lorsque nous aborderons le suivi au niveau de l’application ci-dessous.

Maintenant que nous avons vu à quoi ressemblent la classe et les méthodes et propriétés prises en charge par la classe TraceContext , examinons un exemple de Trace.Write().

<Script runat=server>
Public Function Add(a As Integer, b As Integer) As Integer
  Trace.Write("Inside Add() a: ", a.ToString())
  Trace.Write("Inside Add() b: ", b.ToString())
  return a + b
End Function
</Script>
Call the Add routine: 4 + 5 = <%=Add(4,5)%>

Lorsque ce code est exécuté, la sortie est :

Figure 1. Exemple de méthode Trace.Write()

Évidemment, la méthode Add() est appelée. Toutefois, contrairement aux instructions Repsonse.Write(), les instructions Trace.Write() n’apparaissent pas dans la sortie obtenue. Pour afficher les résultats des instructions Trace.Write(), nous devons activer le suivi pour cette page ou pour l’application.

Pour activer le suivi, nous pouvons utiliser une directive de page ou une option de configuration. Examinons les deux.

Directive de suivi de page

Les directives de page sont des instructions spéciales que ASP.NET utilise lors du traitement d’une demande pour une ressource ASP.NET. Les directives de page peuvent être utilisées pour remplacer ou appliquer des paramètres de configuration pour une page ASP.NET.

Une directive doit être le premier élément d’une page. Il est déclaré à l’aide de la syntaxe suivante :

<%@ Directive Attribute="[Value]" %>

À l’aide de la syntaxe ci-dessus, voici comment indiquer à ASP.NET que nous souhaitons que le suivi soit activé sur une page :

<%@ Page Trace="true" %>

Si nous ajoutons la directive ci-dessus à notre exemple de code, la sortie de notre page est très différente :

Figure 2 : Suivi activé

Nous obtenons maintenant la sortie de suivi ajoutée au bas de la page. La sortie de trace est toujours ajoutée à la fin de la page.

Voyons ensuite comment nous activerons le suivi au niveau de l’application. Ensuite, nous aborderons ce que contient la sortie de trace.

Trace d’application

ASP.NET utilise des fichiers de configuration XML pour définir les paramètres de configuration des applications ASP.NET. Chaque installation ASP.NET installe un fichier de configuration dans le répertoire [lecteur système]\WinNt\Microsoft.NET\Framework\[version]\ nommé config.web.

Le fichier de configuration définit la configuration par défaut ASP.NET, et dans bêta 1 est appelé fichier de configuration racine. Les modifications apportées dans ce fichier affectent l’ensemble de notre application web ASP.NET. Nous pouvons également utiliser des fichiers de configuration dans nos applications web pour ajouter ou supprimer des paramètres acquis à partir du fichier config.web par défaut.

J’aborderai la configuration plus en détail dans une prochaine colonne. Pour l’instant, nous allons utiliser le fichier de configuration racine pour appliquer les paramètres de suivi à toutes les applications ASP.NET.

Section Trace

Si nous ouvrons le fichier config.web racine, nous trouverons une section de suivi :

<configuration>
    <trace
        enabled="false"
        requestlimit="10"
        pageoutput="false"
        tracemode="SortByTime"
    />
</configuration>

Il existe quatre attributs pour l’élément trace :

• enabled = « [true/false]" : nous pouvons définir l’option activée sur true ou false. Le suivi est activé au niveau de l’application ou désactivé au niveau de l’application. Si nous définissons enabled=false, le suivi de page est toujours pris en charge à l’aide de la directive Trace décrite précédemment.
• requestlimit =  » [int]": nombre total de demandes de trace à conserver en mémoire cache par application. Le suivi expose une ressource spéciale( Trace.axd, que nous allons examiner à présent) qui est utilisée pour afficher la sortie de trace lorsque pageoutput a la valeur false.
• pageoutput =  » [true/false]"— Lorsque le suivi est activé via le fichier de configuration, l’administrateur peut activer ou désactiver le suivi sur chaque page. Le suivi pageoutput active les détails de suivi pour chaque page au sein d’une application. Toutefois, le suivi pageoutput peut être désactivé tant que le suivi au niveau de l’application est toujours activé (true" activé = "). Cela conserve les requêtes de trace en mémoire, de sorte qu’elles soient disponibles via trace.axd, que nous allons examiner momentanément, mais pas affichées dans la sortie d’une page.
• tracemode = "[SortByTime | SortByCategory]" : le paramètre tracemode nous permet de contrôler la sortie des informations de détail de trace. Les données peuvent être triées par heure ou par catégorie, où la catégorie est différenciée entre les paramètres effectués par le système et les paramètres Trace.Write() activés par le développeur. Par exemple, dans notre exemple, nous avons utilisé les éléments suivants : Trace.Write("Inside Add() a:", a.ToString()). Le premier paramètre de l’instruction Trace.Write() est la catégorie. Dans ce cas, nous avons défini la catégorie "comme Inside Add() a:". Si nous trions par catégorie (tracemode = « SortByCategory"), cet élément est trié avant les appels de la fonction de page normale dans la sortie de trace. Le tri par heure, d’autre part, trie en fonction du temps passé dans l’appel.

Utilisation du suivi d’application

À l’aide du même exemple de code ci-dessus, nous pouvons supprimer la directive de page et activer la même fonctionnalité en modifiant les paramètres config.web de suivi.

<configuration>
    <trace
        enabled="true"
        requestlimit="10"
        pageoutput="true"
        tracemode="SortByTime"
    />
</configuration>

Nous pouvons maintenant appeler notre exemple d’application, en supprimant la directive Page , et obtenir la même sortie :

Figure 3. Suivi activé, aucune directive Page

Mais que se passe-t-il si nous voulons utiliser la fonctionnalité mentionnée précédemment, dans laquelle nous activons le suivi, mais nous désactivons la sortie sur la page ?

<configuration>
    <trace
        enabled="true"
        requestlimit="10"
        pageoutput="false"
        tracemode="SortByTime"
    />
</configuration>

Si nous avons demandé l’exemple d’application avec les paramètres de configuration ci-dessus, nous n’obtiendrons aucune sortie de suivi, bien que le suivi soit toujours activé. Pour afficher la sortie de trace, nous utilisons une application spéciale appelée trace.axd.

Trace.axd

Trace.axd est un gestionnaire Http. Un gestionnaire Http est une option de codage qui nous permet de gérer les requêtes/réponses au niveau le plus simple. Les gestionnaires Http sont l’équivalent des extensions ISAPI. Toutefois, contrairement à ISAPI, ils peuvent être créés à l’aide de n’importe quel langage .NET. J’aborderai les gestionnaires Http plus en détail dans une colonne ultérieure.

Trace.axd est un gestionnaire Http que nous pouvons utiliser pour demander des détails de trace d’application. À la demande, nous recevons un journal de trace des n dernières demandes ; n est déterminé par la valeur définie par requestlimit="[int] » dans notre fichier de configuration.

Pour utiliser trace.axd, il vous suffit de demander trace.axd dans le même répertoire d’application que celui où la demande pour l’exemple d’application a été effectuée :

Figure 4. Demandes de trace d’application

Comme vous pouvez le voir dans la capture d’écran, une liste de traces que nous pouvons afficher s’affiche. Ces affichages de trace sont identiques aux détails que le suivi ajouterait à la page, sans la sortie de la page incluse :

Figure 5. Détails de la requête

Maintenant que nous avons décrit la façon dont nous configurons et utilisons le suivi, nous allons aborder la sortie de trace.

Interprétation de la sortie de trace

La sortie fournie par la vue de suivi, via Trace.axd ou sur une page, fournit six sections de détails :

• Détails de la demande : il s’agit d’informations de base, telles que l’ID de session, l’heure de la demande, le type de requête Http et le code de status de réponse Http.
• Informations de trace : cette section fournit une vue de tableau des catégories et des messages. Si nous utilisons des instructions Trace.Write() dans notre code, les deux paramètres acceptés par Trace.Write() sont utilisés comme valeurs Category et Message , respectivement. En outre, nous disposons de l’heure comprise entre le premier et le dernier octet.
• Arborescence de contrôles : bien que cela ne soit pas encore abordé dans cette colonne, ASP.NET utilise des contrôles serveur pour nous permettre de créer des applications de manière déclarative. La section Arborescence des contrôles nous fournit des informations sur les contrôles dans notre page. Nous sommes fournis avec l’ID, le type, la taille de rendu et la taille de l’état d’affichage du contrôle. Ces informations nous donnent une idée des contrôles que nous utilisons, ainsi que du coût associé (taille de rendu et état d’affichage).
• Collection de cookies : tous les cookies envoyés par le client dans les en-têtes de requête sont analysés et leurs noms, valeurs et tailles sont affichés.
• Collection d’en-têtes : les en-têtes Http présentés par le client au serveur sont fournis dans cette section. Il s’agit d’une table simple qui répertorie nom/valeur.
• Variables de serveur : la section variables de serveur présente une table de paires Nom/Valeur de variables de serveur.

Utilisation du suivi

Comme vous pouvez le voir clairement, le traçage est une nouvelle fonctionnalité ASP.NET puissante conçue pour faciliter le développement d’applications web. Cependant, j’ai pensé qu’il serait également utile de mention quand vous devriez et ne devriez pas utiliser le traçage.

Applications déployées

Le suivi ajoute une surcharge supplémentaire aux demandes et ne doit pas être activé pour les applications déployées. Toutefois, les instructions Trace.Write() peuvent être laissées dans, car elles sont ignorées lorsque le traçage n’est pas activé.

Pour les applications déployées dans lesquelles nous souhaitons capturer des données, je suggère d’utiliser les classes trouvées dans l’espace de noms System.Diagnostics . Ces classes, que je vais essayer de couvrir dans une prochaine colonne, nous permettent d’écrire directement dans le journal des événements Windows.

Nous devons certainement utiliser le suivi lorsque nous créons une application, mais le désactiver lorsque nous sommes prêts à déployer l’application, tout comme nous aurions supprimé ces instructions Response.Write().

Désactivation de Trace.axd

Si vous avez installé ASP.NET sur un serveur Web de production, je vous recommande de désactiver explicitement Trace.axd. Ouvrez le fichier config.web racine, recherchez la <httphandlers> section et ajoutez l’entrée suivante :

<configuration>
        <add verb="*" 
             path="trace.axd"
             type="System.Web.Handlers.TraceHandler" />
        <remove verb="*" path="trace.axd"/>
</configuration>

Note: Nous pourrions également couper l’entrée entière <add/> , mais l’option <remove> est meilleure, car elle laisse le code dans notre fichier de configuration et accomplit le même objectif, en désactivant trace.axd. Ce problème sera résolu dans la version bêta 2 de ASP.NET.

Résumé

La fonctionnalité de suivi dans ASP.NET est un nouveau moyen puissant de suivre ce que fait notre application. Dans le passé, nous utilisions des instructions Response.Write() pour suivre notre application telle qu’elle s’exécutait, mais nous pouvons maintenant utiliser des instructions Trace.Write() et laisser ces instructions dans notre code déployé. Cela entraîne moins de bogues, car nous ne supprimons pas le code lorsque nous sommes prêts à déployer l’application.

ressources ASP.NET

Enfin, je voulais vous présenter quelques-unes des nouvelles ressources ASP.NET disponibles. Visitez pour https://www.asp.net en savoir plus sur les ressources ASP.NET.

• Eraserver.net offre un hébergement pour ASP.NET.

Rob Howard est responsable de programme pour ASP.NET de l’équipe .NET Framework. Il passe tout son temps libre avec sa famille ou la pêche à la mouche dans l’est de Washington.