Utilisation de modules et de gestionnaires HTTP pour créer des composants ASP.NET enfichables

  • Article

 

Scott Mitchell, 4GuysFromRolla.com
Atif Aziz, Skybow AG

Septembre 2004

Résumé : Dans cet article, Scott Mitchell et Atif Aziz montrent comment utiliser des modules et des gestionnaires HTTP pour ajouter la journalisation des erreurs à vos applications ASP.NET. (22 pages imprimées)

Téléchargez l’exemple de fichier MSDNElmah.msi.

Contenu

Introduction
ELMAH : Modules et gestionnaires de journalisation des erreurs
Brève vue d’ensemble des gestionnaires et modules HTTP
Examen de l’architecture d’ELMAH
Ajout d’ELMAH à une application web ASP.NET
Conclusion
Références
Ouvrages connexes

Introduction

Avez-vous déjà travaillé sur une application ASP.NET et conçu des fonctionnalités utiles ou un ensemble de fonctionnalités que vous souhaitez pouvoir réutiliser facilement dans une autre application ASP.NET ? ASP.NET propose différents outils pour la création de composants de différents types de fonctionnalités. Les deux outils les plus courants à réutiliser dans ASP.NET sont les suivants :

  • Contrôles utilisateur et contrôles serveur personnalisés compilés pour les éléments et fonctionnalités de l’interface utilisateur.
  • Bibliothèques de classes .NET pour la logique métier et le code d’accès aux données.

Les modules et les gestionnaires HTTP sont deux ASP.NET réutiliser des outils qui n’obtiennent pas beaucoup d’attention.

Si vous n’êtes pas familiarisé avec les gestionnaires et modules HTTP, ne vous inquiétez pas. Nous en parlerons plus loin dans cet article. Pour l’instant, il suffit de comprendre que les modules HTTP sont des classes qui peuvent être configurées pour s’exécuter en réponse à des événements qui se déclenchent pendant la demande d’une ressource ASP.NET. Un gestionnaire HTTP est une classe qui est responsable du rendu d’une ressource particulière ou d’un type particulier de ressource. En fait, chaque fois que vous ajoutez une page web ASP.NET à votre projet, vous écrivez essentiellement un gestionnaire HTTP. En effet, lorsque la partie HTML d’une page web ASP.NET est compilée dynamiquement au moment de l’exécution, elle hérite directement ou indirectement de System.Web.UI.Page, qui se trouve être une implémentation de gestionnaire HTTP. Cela est vrai, que vous preniez la stratégie inline ou code-behind.

Comme vous le savez, une application ASP.NET se compose généralement d’un ensemble de pages Web, qui sont appelées lorsqu’elles sont demandées par le navigateur d’un utilisateur final. En tant que développeurs ASP.NET, la plupart du code que nous écrivons est spécifique à une demande pour une page Web particulière, comme le code dans la classe code-behind d’une page particulière pour afficher les résultats de la base de données en fonction d’une requête de recherche. Toutefois, il est parfois nécessaire d’écrire du code orthogonal pour une seule page Web, code qui s’applique à toutes les pages d’une application. Par exemple, nous pourrions souhaiter suivre l’ordre dans lequel chaque utilisateur se déplace sur notre site Web. Pour ce faire, nous devons que chaque page enregistre l’heure de la demande et des informations identifiant l’utilisateur.

Une façon de fournir ces fonctionnalités de journalisation consiste à ajouter du code qui a enregistré les données germanes dans une base de données dans le Page_Load gestionnaire d’événements pour chaque page Web du site. Toutefois, cette approche est difficilement maintenable ou réutilisable. Chaque fois que nous ajoutons une nouvelle page ASP.NET dans notre site, nous devons nous assurer que nous avons inclus le code de journalisation approprié. Si nous voulions ajouter des fonctionnalités similaires à un autre site, nous devons parcourir chaque page de ce site et ajouter le code requis. Dans l’idéal, la fonctionnalité de journalisation serait logiquement et physiquement distincte de la fonctionnalité de chaque page individuelle, et l’ajouter à un autre site serait aussi simple que de supprimer un assembly dans le répertoire du /bin site.

Cette réutilisation et cette facilité de maintenance sont tout à fait possibles avec les modules et gestionnaires HTTP. Dans cet article, nous allons examiner un ensemble de modules et de gestionnaires HTTP qui ont été conçus pour faire de la journalisation des erreurs un exercice hautement maintenable et réutilisable. L’objectif de cet article est de montrer comment les gestionnaires et modules HTTP peuvent être utilisés comme une forme de composantisation de très haut niveau, ce qui permet de développer, empaqueté et déployer des ensembles entiers de fonctionnalités en une seule unité et indépendamment des applications web. Nous allons atteindre cet objectif en grande partie par l’examen d’une application qui bénéficie de la réutilisation et de la composantisation via des gestionnaires et des modules HTTP.

ELMAH : Modules et gestionnaires de journalisation des erreurs

Les Error Logging Modules And Handlers (ELMAH), que nous allons examiner tout au long de cet article, ont été écrits par le co-auteur Atif Aziz (http://www.raboof.com/) et montrent un moyen facile d’ajouter des fonctionnalités de journalisation des erreurs à une application web ASP.NET. ELMAH illustre comment les modules et les gestionnaires HTTP peuvent être utilisés pour fournir un degré élevé de composantisation pour le code qui est orthogonal pour l’application web (par exemple, la journalisation à l’échelle de l’application). ELMAH est une solution vraiment enfichable, ce qui signifie qu’elle peut être ajoutée dynamiquement à une application web ASP.NET en cours d’exécution sans besoin de recompilation ou de redéploiement.

Quelle que soit la façon dont une application web particulière est bien écrite et testée, les choses vont toujours mal tourner de temps en temps. Il peut ne pas s’agir de votre code en cause, du fait que le serveur de messagerie ne répond pas ou qu’une altération des données provoque un échec de chiffrement. Quelle que soit la raison, lorsqu’une exception se produit, en particulier sur un site en direct, il est important que les détails de l’exception soient enregistrés afin de faciliter le diagnostic du problème. ELMAH fournit un mécanisme pour la journalisation et la notification centralisées des erreurs. Chaque fois qu’une exception se produit dans une application ASP.NET qui n’est pas interceptée, ELMAH est averti et gère l’exception comme indiqué dans le fichier Web.config . Cela peut inclure l’enregistrement des détails de l’exception dans une base de données, l’envoi d’un e-mail à un administrateur, ou les deux.

ELMAH n’est pas conçu pour répondre correctement aux exceptions non gérées. Il enregistre simplement les détails des exceptions non gérées. Une fois QU’ELMAH a été ajouté à une application web ASP.NET, toutes les exceptions non gérées déclenchées dans cette application sont journalisées. ELMAH n’affecte pas l’expérience de l’utilisateur final lorsqu’une exception non gérée se produit. Ils voient toujours la page « Erreur du serveur » ou, si des erreurs personnalisées sont configurées pour gérer les erreurs HTTP 500, elles sont redirigées vers une page avec un message plus convivial. Mais en arrière-plan, ELMAH aura détecté qu’une exception non gérée s’est produite et enregistré les détails.

ELMAH détecte les exceptions non gérées par le biais de l’événement Error de l’objet HttpApplication. L’événement Error est déclenché chaque fois qu’une exception non interceptée se déclenche pendant le traitement de la demande, que ce soit à partir d’une bibliothèque de classes .NET ou d’une page Web ASP.NET. Gardez à l’esprit que de nombreuses applications ASP.NET implémentent de manière incorrecte les pages d’erreurs personnalisées et la gestion en appelant la méthode Server.ClearError(). L’effacement de l’erreur empêche l’événement Error de se déclencher (et d’être signalé au client) et ELMAH n’aura donc jamais la possibilité de journaliser l’exception. Autrement dit, lors de l’utilisation ClearError() dans une page d’erreur personnalisée, votre utilisateur verra qu’un problème s’est produit, mais vous ne le serez pas.

Note Pour plus d’informations sur la création de pages d’erreurs personnalisées, consultez l’article d’Eli Robillard Gestion des erreurs personnalisées enrichies avec ASP.NET.

Note Lorsqu’une exception non gérée se produit dans un service Web ASP.NET, l’événement Error n’est pas en bulles jusqu’aux modules HTTP et, par conséquent, ELMAH. Au lieu de cela, il est intercepté par le runtime ASP.NET et une erreur SOAP est retournée au client. Pour qu’une erreur soit enregistrée dans un service Web, vous devez créer une extension SOAP qui écoute les erreurs SOAP.

Outre l’enregistrement des détails des exceptions non gérées, ELMAH est également fourni avec un ensemble de gestionnaires HTTP pour afficher le journal des erreurs. Il existe une interface web du journal, qui peut fournir une liste de toutes les erreurs non gérées, ainsi que des détails sur une erreur particulière (voir les figures 1 et 2).

Aa479332.elmah_fig01(en-us,MSDN.10).gif

Figure 1. Affichage du journal des erreurs

Aa479332.elmah_fig02(en-us,MSDN.10).gif

Figure 2 : Affichage d’une erreur

Ce journal des erreurs peut également être affiché en tant que RSS, ce qui permet à un administrateur de recevoir des notifications par l’intermédiaire de son agrégateur RSS favori lorsqu’une erreur s’est produite (voir la figure 3).

Aa479332.elmah_fig03(en-us,MSDN.10).gif

Figure 3. Flux RSS d’erreurs

Note RSS, qui signifie Really Simple Syndication, est une norme au format XML couramment utilisée pour syndiquer des actualités et d’autres types de contenu changeant. Pour en savoir plus sur RSS, notamment sur la façon de syndiquer du contenu à l’aide de RSS, ainsi que sur la création d’un lecteur RSS basé sur le web, consultez Création d’un agrégateur d’actualités en ligne avec ASP.NET.

Par souci de concision, cet article traite uniquement d’un sous-ensemble des fonctionnalités d’ELMAH, en se concentrant sur les composants clés. Le code complet est disponible en téléchargement avec cet article et nous vous encourageons à l’étudier minutieusement pour obtenir les détails de l’implémentation. Il existe également une configuration d’espace de travail GotDotNet pour ELMAH à http://workspaces.gotdotnet.com/elmah des fins de discussion, de signalement de problèmes et de rester à jour avec les modifications.

Solutions existantes pour la journalisation centralisée des erreurs

Bien que ASP.NET ne fournisse pas de fonctionnalités intégrées & de journalisation et d’affichage des erreurs, le groupe Modèles pratiques de Microsoft a créé un journal d’erreurs open source, le bloc d’application de gestion des exceptions (EMAB). L’EMAB a été conçu pour fonctionner à la fois avec les applications de bureau et .NET basées sur le web, mais on ne peut pas s’empêcher de penser que l’EMAB a été principalement conçu pour les applications de bureau avec des applications web comme une pensée ultérieure, car l’EMAB, par défaut, publie les détails des exceptions dans le journal des événements Windows. Bien que le journal des événements soit un magasin de stockage approprié pour obtenir des informations concises sur les exceptions pour une application de bureau, la plupart des applications Web, en particulier celles hébergées sur un serveur partagé dans une société d’hébergement Web, évitent le journal des événements, car l’utilisation du journal des événements nécessite l’établissement d’autorisations spéciales pour permettre à l’application ASP.NET d’écrire dans le journal des événements. Certes, l’EMAB est suffisamment flexible pour vous permettre de créer un éditeur personnalisé qui enregistre des informations dans une base de données, mais il s’agit d’une étape supplémentaire que vous, le développeur, êtes chargé de suivre.

Note ELMAH est fourni avec un module de journalisation de base de données pour Microsoft SQL Server 2000, que nous aborderons plus tard. Avec ELMAH, vous pouvez également créer des enregistreurs d’événements d’exceptions personnalisés, tels qu’un enregistreur d’événements qui enregistre les détails des exceptions dans un fichier XML sur le système de fichiers du serveur Web. En fait, vous pouvez étendre ELMAH pour utiliser le bloc d’application de gestion des exceptions, si vous aviez déjà un éditeur personnalisé écrit pour l’EMAB que vous souhaitez utiliser.

La façon dont l’EMAB est utilisé pour enregistrer les informations d’exception influence fortement la maintenabilité et la réutilisation de l’application web. Par exemple, une approche naïve de l’enregistrement des informations d’exception consiste à placer un try ...catch bloc autour de chaque bloc de code dans chaque page web ASP.NET, en appelant l’EMAB dans la catch section .

private void Page_Load(object sender, EventArgs e)
{
  try {
    // Code that might cause an exception
  }
  catch (Exception ex) {
    // record exception information by calling exception logger library
  }
}

Cette approche est stupide, car elle associe étroitement la journalisation des exceptions à chaque page web ASP.NET, ce qui la rend tout sauf maintenable ou réutilisable. Une meilleure approche consisterait à utiliser l’EMAB dans l’événement Application_Errordans Global.asax. Cette approche offre une architecture plus faiblement couplée, maintenable et réutilisable, car le code de publication d’exception ne touche pas ASP.NET page Web et se trouve à la place dans un emplacement centralisé. L’inconvénient de cette approche est qu’elle n’est pas enfichable. Pour ajouter cette fonctionnalité de journalisation des erreurs à une autre application web ASP.NET, vous devez modifier la valeur de Global.asaxcette application , ainsi nécessaire pour recompiler et redéployer l’application.

Le but de cet article n’est pas d’introduire un remplacement pour l’EMAB. Il s’agit plutôt de mettre en évidence la création de composants rendue possible par les gestionnaires et modules HTTP. ELMAH illustre comment effectuer une tâche commune, telle que la journalisation des erreurs centralisée, et la composant pour faciliter la maintenance et offrir un haut degré de réutilisation. L’objectif d’ELMAH est de fournir des conseils pour la composantation des fonctionnalités applicables.

Brève vue d’ensemble des gestionnaires et modules HTTP

Avant de passer à l’examen des spécificités de l’architecture et de l’implémentation d’ELMAH, prenons un moment pour passer en revue les gestionnaires et modules HTTP. Chaque fois qu’une demande arrive sur un serveur Web IIS, IIS examine l’extension de la demande pour décider de la procédure à suivre. Pour le contenu statique comme les pages HTML, les fichiers CSS, les images, les fichiers JavaScript, etc., IIS gère la requête elle-même. Pour le contenu dynamique comme les pages ASP, les pages web ASP.NET et les services web ASP.NET, IIS délègue la demande à une extension ISAPI spécifiée. Une extension ISAPI est un morceau de code non managé qui sait comment restituer des requêtes d’un type particulier. Par exemple, l’extension asp.dll ISAPI est responsable du rendu des requêtes pour les pages web ASP classiques ; l’extension aspnet_isapi.dll ISAPI est appelée lorsqu’une demande arrive pour une ressource ASP.NET.

En plus des extensions ISAPI, IIS autorise également les filtres ISAPI. Un filtre ISAPI est un morceau de code non managé qui peut s’exécuter en réponse aux événements déclenchés par IIS. Pendant le cycle de vie d’une requête, IIS passe par un certain nombre d’étapes qui déclenchent des événements correspondants. Par exemple, un événement est déclenché lorsque la demande atteint IIS pour la première fois, lorsque la demande est sur le point d’être authentifiée, lorsque le contenu rendu est sur le point d’être renvoyé au client, et ainsi de suite. Les filtres ISAPI sont couramment utilisés pour fournir des fonctionnalités telles que la réécriture d’URL, la compression, l’authentification et l’autorisation spécialisées, la journalisation spécialisée, etc.

Lorsqu’une demande d’une ressource ASP.NET atteint IIS, elle est acheminée vers le moteur ASP.NET, qui affiche le contenu de la ressource demandée. Le moteur ASP.NET se comporte beaucoup comme IIS en ce qu’il déclenche un certain nombre d’événements lorsque la requête passe par le pipeline HTTP ASP.NET. En outre, le moteur ASP.NET délègue le rendu de la ressource demandée à une classe particulière. Alors qu’IIS utilise des extensions et des filtres ISAPI non managés, ASP.NET utilise des classes managées appelées gestionnaires et modules HTTP.

Un gestionnaire HTTP est une classe qui est responsable du rendu d’un type particulier de ressource. Par exemple, la classe code-behind d’une page web ASP.NET est un gestionnaire HTTP, qui sait comment restituer le balisage pour une page web particulière. Il est utile de considérer les gestionnaires comme des renderers spécialisés qui savent comment créer le balisage pour un type particulier de ressource.

Note Pour une discussion plus approfondie sur les gestionnaires HTTP, ainsi que sur certaines applications pratiques des gestionnaires, veillez à lire Servir du contenu dynamique avec des gestionnaires HTTP.

Un module HTTP est une classe qui peut exploiter les différents événements déclenchés quand une requête passe à travers les étapes de son cycle de vie sur le serveur. L’un de ces ASP.NET événement d’application est l’événement Error , qui se déclenche lorsqu’une exception non prise en charge se produit, c’est-à-dire l’événement qui intéresse ELMAH.

Note Pour plus d’informations sur les modules HTTP, notamment sur l’utilisation des modules HTTP pour implémenter la réécriture d’URL, case activée la réécriture d’URL dans ASP.NET.

La figure 4 fournit une représentation graphique du pipeline HTTP ASP.NET. Notez que le processus commence par une requête arrivant à IIS. En supposant que la ressource demandée est configurée pour être gérée par l’extension ISAPI ASP.NET, IIS distribue la demande à l’extension ISAPI non managée aspnet_isapi.dll . Cette extension ISAPI transmet la demande au moteur de ASP.NET managé. Pendant le cycle de vie de la demande, un ou plusieurs modules HTTP peuvent s’exécuter, en fonction des modules qui ont été inscrits et des événements auxquels ils se sont abonnés. Enfin, le moteur de ASP.NET détermine le gestionnaire HTTP qui est responsable du rendu du contenu, en appelant le gestionnaire et en renvoyant le contenu généré à IIS, qui le renvoie au client demandeur.

Aa479332.elmah_fig04(en-us,MSDN.10).gif

Figure 4. Flux de données via l’enregistreur d’erreurs

ELMAH fournit une journalisation centralisée des erreurs via un module HTTP qui a un gestionnaire d’événements pour l’événement Error . Lorsque l’événement se déclenche, ELMAH consigne les détails de l’exception. ELMAH utilise également des gestionnaires HTTP qui sont principalement responsables de la génération du balisage HTML et RSS pour afficher des informations à partir du journal des erreurs.

La configuration d’une application web existante pour utiliser différents gestionnaires ou modules s’effectue en copiant le module ou l’assembly de gestionnaire dans le répertoire de /bin l’application web et en ajoutant quelques lignes de configuration au Web.config fichier.

Pour configurer les modules HTTP pour une application web, incluez une <section httpModules> au Web.config fichier qui spécifie le type du module à ajouter :

<httpModules>
   <add name="ModuleName" type="ModuleType" />
</httpModules>

Le ModuleType est une chaîne qui indique le type du module, qui est le nom de classe complet (Namespace.ClassName) suivi du nom de l’assembly. L’attribut type peut également inclure des informations de gestion de version et de culture, ainsi qu’un jeton de clé publique requis pour les assemblys nommés avec un nom fort. L’extrait de code suivant montre le paramètre réel <httpModules> que vous devez utiliser pour inclure le module de journalisation des erreurs d’ELMAH dans votre application ASP.NET :

<httpModules>
  <add name="ErrorLog" type="GotDotNet.Elmah.ErrorLogModule, 
    GotDotNet.Elmah, Version=1.0.5527.0, Culture=neutral, 
    PublicKeyToken=978d5e1bd64b33e5" />
</httpModules>

Un gestionnaire HTTP peut être utilisé dans une application web en ajoutant une <section httpHandlers> au Web.config fichier. Étant donné qu’un gestionnaire HTTP affiche le contenu d’un type particulier de ressource, en plus d’un type attribut, l’élément <httpHandlers> contient un path attribut, qui indique les chemins d’accès ou extensions de fichiers qui doivent être mappés à ce gestionnaire HTTP. Il existe également un verb attribut qui vous permet de limiter l’utilisation du gestionnaire à des types spécifiques de requêtes HTTP, comme dans une requête GET ou POST. L’exemple suivant crée un gestionnaire HTTP appelé pour toutes les requêtes adressées aux fichiers avec une .ashx extension.

<httpHandlers>
   <add verb="*" path="*.ashx" type="HandlerType" />
</ httpHandlers >

L’attribut type du gestionnaire HTTP est exprimé à l’aide des mêmes options de syntaxe qu’avec les modules HTTP. Ces paramètres dans le Web.config peuvent également être placés dans le fichier machine.config , ce qui a pour effet d’activer les gestionnaires et modules pour toutes les applications web sur le serveur. L’extrait de code suivant montre l’élément <httpHandlers> dans le Web.config fichier dans la démonstration incluse dans le téléchargement de cet article. Notez qu’il indique que toutes les demandes entrantes à /elmah/default.aspx doivent être rendues par la ErrorLogPageFactory classe .

<httpHandlers>
    <add 
        verb="POST,GET,HEAD" 
        path="elmah/default.aspx" 
        type="GotDotNet.Elmah.ErrorLogPageFactory, 
          GotDotNet.Elmah, Version=1.0.5527.0, Culture=neutral, 
          PublicKeyToken=978d5e1bd64b33e5" />
</httpHandlers>

Comme vous pouvez le voir, l’ajout de modules et de gestionnaires HTTP à une application web ASP.NET est très simple, peut être effectué en quelques secondes et ne nécessite aucune recompilation ou redéploiement de l’application ASP.NET. C’est pourquoi les modules et les gestionnaires HTTP constituent un excellent outil de réutilisation et permettent de créer un moyen de composantr votre application en éléments faiblement couplés et hautement gérables.

Examen de l’architecture d’ELMAH

L’architecture d’ELMAH est composée de trois sous-systèmes :

  • Sous-système de journalisation des erreurs
  • Sous-système de module HTTP
  • Sous-système de gestionnaire HTTP

Le sous-système de journalisation des erreurs est responsable de deux tâches : l’enregistrement des erreurs dans le journal et la récupération des informations d’erreur à partir du journal. Le sous-système de module HTTP est responsable de la journalisation d’une erreur lorsqu’une exception non gérée se produit dans l’application ASP.NET. Le sous-système de gestionnaire HTTP fournit un moyen de rendre le journal des erreurs dans le balisage, constituant une interface web du journal des erreurs, ainsi qu’un flux RSS.

Comme le montre la figure 5, le module HTTP et les sous-systèmes de gestionnaire utilisent tous deux le sous-système de journalisation des erreurs. Le sous-système de module HTTP envoie les informations d’exception au sous-système de journalisation des erreurs, tandis que le sous-système de gestionnaire HTTP lit et affiche les informations d’erreur.

Aa479332.elmah_fig05(en-us,MSDN.10).gif

Figure 5. Emplacement du système de journalisation des erreurs

Pour mieux comprendre l’architecture d’ELMAH, examinons chacun de ces trois sous-systèmes plus en détail.

Sous-système de journalisation des erreurs

Le sous-système de journalisation des erreurs est responsable de l’enregistrement des erreurs dans le journal, ainsi que des fonctionnalités permettant de récupérer des détails sur une erreur particulière ou un sous-ensemble des erreurs. Cette fonctionnalité est mise à disposition par un certain nombre de classes :

  • Errorlog: Cette classe abstraite fournit les méthodes contractuelles pour lire et écrire dans le journal.
  • Erreur: Cette classe contient des propriétés qui décrivent les détails d’une erreur particulière.
  • ErrorLogEntry : Cette classe représente un instance particulier Error pour un particulier ErrorLog. Le ErrorLogEntry groupe regroupe essentiellement un Error instance avec le ErrorLog instance d’où il provient.

Examinons ces trois classes et leur fonctionnement avec les modules HTTP et les sous-systèmes de gestionnaire HTTP afin de fournir un utilitaire de journalisation des exceptions complet et centralisé.

Examen de la classe ErrorLog

Selon la configuration ou la stratégie d’un projet particulier, vous pouvez utiliser un autre magasin de stockage pour le journal des erreurs. Par exemple, sur un serveur de production, vous pouvez enregistrer des exceptions dans Microsoft SQL Server, mais sur un serveur de développement, vous pouvez simplement stocker les erreurs dans un ensemble de fichiers XML ou une base de données Microsoft Access. Pour offrir la possibilité d’utiliser différents magasins de stockage, le sous-système de journalisation des erreurs fournit une classe de base abstraite, ErrorLog, qui définit les méthodes de base que tous les enregistreurs d’erreurs ELMAH doivent implémenter. Ces méthodes sont les suivantes :

  • Log(Error) : Consigne une erreur dans le magasin de stockage. La Error classe représente des informations sur une exception non prise en charge. Nous aborderons cette Error classe plus en détail sous peu. Lors de la journalisation des informations d’erreur, la Log() méthode doit également affecter un identificateur unique à l’erreur.
  • GetError(id) : Retourne des informations sur une erreur particulière dans le journal.
  • GetErrors (...) : Retourne un sous-ensemble d’erreurs du journal. Cette méthode est utilisée par le sous-système du gestionnaire HTTP pour afficher le journal des erreurs de manière paginée, plutôt que d’afficher toutes les erreurs à la fois.

ELMAH est livré avec deux ErrorLog implémentations :

  • SqlErrorLog : Enregistre les erreurs dans une base de données Microsoft SQL Server 2000 à l’aide du System.Data.SqlClient fournisseur. Le SqlErrorLog nécessite SQL Server 2000, car il tire parti de certaines de ses fonctionnalités XML, mais il s’agit d’un détail d’implémentation qui peut être modifié.
  • MemoryErrorLog : Enregistre les erreurs dans la mémoire (RAM) de l’application. En d’autres termes, il est lié à AppDomain de sorte que chaque application reçoit son propre journal privé. Inutile de dire que ce journal ne survivra pas aux redémarrages ou à la durée de vie de l’application. Il est donc principalement utile à des fins de test et de résolution des problèmes temporaires lorsque d’autres implémentations peuvent échouer.

Vous pouvez utiliser l’un de ces enregistreurs d’événements d’exception en ajoutant simplement quelques lignes de texte au fichier de Web.config votre application web ASP.NET. Si vous devez stocker les détails de l’erreur à un emplacement autre que SQL Server ou la mémoire de l’application, vous pouvez créer votre propre journal d’événements personnalisé. Pour implémenter un enregistreur d’erreurs pour ELMAH, créez une classe qui étend ErrorLog et fournit l’implémentation pour , Log()GetError()et GetErrors() par rapport à votre magasin souhaité.

Sachez que le module HTTP et les sous-systèmes de gestionnaire dans ELMAH interagissent directement avec la classe spécifiée ErrorLog , que ce SqlErrorLogsoit , MemoryErrorLogou votre propre classe de journal personnalisée. Le module HTTP consigne les informations d’exception en créant une Error instance et en la transmettant à la méthode de Log() la ErrorLog méthode. Les gestionnaires HTTP lisent des détails sur une ou plusieurs erreurs par le ErrorLogbiais des GetError() méthodes et GetErrors() qui retournent un instance spécifique ErrorLogEntry ou un ensemble d’instancesErrorLogEntry.

Un aperçu de la classe Error

La Log() méthode de ErrorLog attend un paramètre d’entrée de type Error. Une classe personnalisée Error est utilisée à la place de la Exception classe fournie dans le .NET Framework, car elle est plus adaptée à la Exception communication des informations d’exception dans la pile de code et pendant la durée de vie d’une application. Toutefois, Exception les objets ne sont pas idéaux pour le stockage dans un journal des exceptions en raison de problèmes de stockage, de saisie et de portabilité. Oui, la sérialisation binaire peut être utilisée pour stocker un Exception instance, mais cela nécessite que l’objet Exception soit désérialisable sur une machine avec le même ensemble de types et d’assemblys disponibles. Il s’agit d’une limitation inacceptable (en particulier du point de vue de l’administration et des opérations), car un journal et son contenu doivent être portables et ne doivent pas uniquement être visibles sur une machine avec un runtime ou une configuration particulière. En outre, une Exception instance manque souvent d’informations périphériques spécifiques à une application web, telles que les valeurs de la collection ServerVariables de la demande web actuelle, ce qui peut être précieux pour le diagnostic. Ainsi, en bref, la Error classe agit comme substitut pour tous les types d’exceptions, en conservant les informations d’une exception levée dans une application web.

La liste complète des Error propriétés est indiquée dans le tableau 1.

Propriété Description
Exception Le Exception instance représenté par cette erreur. Il s’agit d’une propriété d’exécution uniquement qui n’est jamais conservée avec une instance de la classe.
ApplicationName Nom de l’application dans laquelle cette erreur s’est produite.
HostName Nom de l’ordinateur hôte où cette erreur s’est produite. Une bonne valeur par défaut est Environment.MachineName.
Type Type, classe ou catégorie de l’erreur. Il s’agit généralement du nom de type complet (sans la qualification d’assembly) de l’exception.
Source Source de l’erreur, généralement identique à la Message propriété d’un Exception objet.
Message Texte bref décrivant l’erreur, généralement identique à la Message propriété d’un Exception objet.
Détail Texte détaillé de l’erreur, tel que la trace complète de la pile.
Utilisateur L’utilisateur s’est connecté à l’application au moment de l’erreur, comme celle retournée par Thread.CurrentPrincipal.Identity.Name.
Temps Date et heure auxquelles l’erreur s’est produite. C’est toujours à l’heure locale.
StatusCode Le code status retourné dans l’en-tête de réponse à la suite de l’erreur. Par exemple, il s’agit de 404 pour une exception FileNotFoundException. Malheureusement, cette valeur ne peut pas toujours être déterminée de manière fiable à partir de ASP.NET. Dans quelques cas, cette StatusCode valeur peut être signalée comme zéro.
WebHostHtmlMessage Message HTML par défaut que l’hôte web (ASP.NET) aurait généré en l’absence de pages d’erreur personnalisées.
ServerVariables NameValueCollection de variables de serveur web, telles que celles contenues dans HttpRequest.ServerVariables.
QueryString de NameValueCollection variables de chaîne de requête HTTP, telles que celles contenues dans HttpRequest.QueryString.
Formulaire de NameValueCollection variables de formulaire, telles que celles contenues dans HttpRequest.Form.
Cookies de NameValueCollection cookies envoyés par le client, tels que ceux contenus dans HttpRequest.Cookies.

La WebHostHtmlMessage propriété a besoin d’une explication. Si votre application web ASP.NET rencontre une exception non prise en charge et que vous n’avez pas configuré votre application pour utiliser des pages d’erreur personnalisées, vous verrez un écran similaire à celui illustré dans la figure 6. Il s’agit d’un écran chaque ASP.NET développeur a vu beaucoup trop de fois.

Aa479332.elmah_fig06(en-us,MSDN.10).gif

Figure 6. Page Erreur standard

Lorsqu’une exception est levée, le balisage HTML réel de l’écran correspondant est accessible et enregistré dans la WebHostHtmlMessage propriété de la Error classe. Lorsque la page qui affiche des informations détaillées sur une exception particulière est visitée, si la instance correspondante Error a une valeur dans sa WebHostHtmlMessage propriété, le visiteur reçoit un lien vers une page qui affiche l’écran d’informations d’exception réelle (comme celui illustré dans la figure 6). Ce qui est bien ici, c’est que non seulement vous obtenez l’exception journalisée, mais vous pouvez également visiter la page d’erreur d’origine générée par ASP.NET lors de l’examen du journal ultérieurement. Et tout cela pendant que vous avez des erreurs personnalisées activées!

La Error classe a également des méthodes pour sérialiser et désérialiser son état vers et à partir d’un format XML. Pour plus d’informations, consultez FromXml et ToXml dans le code qui l’accompagne.

Classe ErrorLogEntry : association d’une erreur à un errorLog

La dernière classe du sous-système de journalisation des erreurs est la ErrorLogEntry classe, qui associe un Error instance à un ErrorLog instance. Lorsque le sous-système de gestionnaire HTTP appelle la GetError() méthode pour récupérer des informations sur une exception particulière, la GetError() méthode récupère les informations du magasin de stockage spécifique et remplit ces informations dans un ErrorLogEntry instance. La ErrorLogEntry classe contient trois propriétés :

  • Id: ID unique des détails de l’exception.
  • Rapport: Référence au ErrorLog instance qui représente le magasin de stockage.
  • Erreur: Un instance renseigné de la Error classe avec les détails de l’erreur spécifique.

Alors que la GetError() méthode retourne une seule ErrorLogEntry instance, renvoie GetErrors() une liste d’instancesErrorLogEntry. GetErrors() est spécialement conçu pour permettre aux erreurs d’être paginées dans n enregistrements à la fois.

La figure 7 montre une vue mise à jour de l’architecture d’ELMAH, montrant plus de détails dans le sous-système de journalisation des erreurs.

Aa479332.elmah_fig07(en-us,MSDN.10).gif

Figure 7. Architecture mise à jour

Sous-système de module HTTP

ELMAH se compose de deux modules HTTP : ErrorLogModule et ErrorMailModule. ErrorLogModule est un module HTTP qui crée un gestionnaire d’événements pour l’événement de l’application Error . En cas d’exception non prise en charge, le module HTTP obtient l’enregistreur d’erreurs approprié, comme spécifié dans la configuration de l’application, et appelle la Log() méthode dessus, en passant un Error instance renseigné avec les informations de l’exception et du HttpContext pour la requête actuelle. Le code source suivant montre le code germane de la ErrorLogModule classe :

public class ErrorLogModule : IHttpModule
{
    public virtual void Init(HttpApplication application)
    {
        application.Error += new EventHandler(OnError);
    }

    protected virtual ErrorLog ErrorLog
    {
        get { return ErrorLog.Default; }
    }

    protected virtual void OnError(object sender, EventArgs args)
    {
        HttpApplication application = (HttpApplication) sender;
        LogException(application.Server.GetLastError(), 
          application.Context);
    }

    protected virtual void LogException(Exception e, 
      HttpContext context)
    {
        try
        {
            this.ErrorLog.Log(new Error(e, context));
        }
        catch (Exception localException)
        {
            Trace.WriteLine(localException);
        }
    }
}

L’exécution ErrorLogModulede commence dans la Init() méthode, où elle indique au runtime ASP.NET que la OnError() méthode doit être appelée chaque fois que l’événement Error est déclenché. La OnError() méthode fait référence à l’objet HttpApplication et appelle la LogException() méthode, en passant les détails de la dernière exception, ainsi que les HttpContext instance spécifiques à la demande particulière. LogException()appelle simplement la méthode de Log() la classe appropriéeErrorLog, en passant une nouvelle Error instance. (le Error instance constructeur prend un Exception et HttpContext instance et remplit les propriétés en conséquence ; pour plus d’informations, reportez-vous au code source disponible dans le téléchargement.)

contient ErrorLogModule une propriété en lecture seule ErrorLog et retourne le ErrorLog instance retourné par ErrorLog.Default. Default est une propriété statique de type ErrorLog dans la ErrorLog classe . Il consulte la configuration de l’application web pour déterminer la classe à utiliser pour la journalisation des exceptions : SqlErrorLog, MemoryErrorLogou une classe de journalisation des exceptions personnalisée.

Note Dans la section Ajout d’ELMAH à une application web ASP.NET, nous allons examiner comment configurer une application web pour utiliser un enregistreur d’exceptions spécifique. Il est aussi simple que d’ajouter quelques lignes aux Web.config fichiers ou machine.config .

L’autre module HTTP du sous-système de module HTTP est la ErrorMailModule classe, qui envoie un courrier électronique à un administrateur en cas d’exception. Nous ne discuterons pas de ce morceau d’ELMAH, bien que vous puissiez examiner comment utiliser ce module dans les exemples de code disponibles dans le téléchargement de cet article.

Sous-système de gestionnaire HTTP

Rappelez-vous que l’objectif des gestionnaires HTTP est de restituer le contenu d’un type particulier de ressource. Lorsqu’une requête arrive dans le pipeline HTTP ASP.NET, le moteur ASP.NET examine le chemin d’accès demandé et détermine quel gestionnaire HTTP doit être utilisé pour gérer la ressource demandée. Plus précisément, une application ASP.NET peut être configurée pour avoir un chemin d’accès particulier géré par un gestionnaire HTTP ou une fabrique de gestionnaire HTTP. Une fabrique de gestionnaire HTTP est une classe qui n’est pas directement responsable du rendu du contenu, mais qui est plutôt responsable de la sélection et du retour d’un gestionnaire HTTP instance. Ce gestionnaire HTTP retourné instance est alors celui qui est chargé de restituer la ressource demandée.

Le sous-système de gestionnaire HTTP d’ELMAH se compose d’un certain nombre de classes de gestionnaire HTTP conçues pour produire du balisage pour afficher les erreurs journalisées, ainsi qu’une seule classe de fabrique de gestionnaire HTTP. La classe de fabrique du gestionnaire HTTP, ErrorLogPageFactory, examine la PathInfo partie de l’URL demandée pour déterminer quel gestionnaire HTTP doit générer la sortie.

Note La PathInfo partie d’une URL correspond à tout contenu supplémentaire suivant le nom du fichier et est disponible via la propriété PathInfo de l’objetRequest. Par exemple, dans l’URL http://www.example.com/someDir/somePage.aspx/somePath, somePath est la PathInfo partie de l’URL. Pour plus d’informations sur la terminologie utilisée pour les différentes parties d’une URL et les propriétés d’objet correspondantes Request , reportez-vous à l’entrée de blog de Rick Strahl Making Sense of ASP.NET Paths.

L’extrait de code suivant montre le code le plus intéressant de la ErrorLogPageFactory classe de fabrique du gestionnaire HTTP.

public class ErrorLogPageFactory : IHttpHandlerFactory
{
    public virtual IHttpHandler GetHandler(HttpContext context, 
      string requestType, string url, string pathTranslated)
    {
        string resource = 
          context.Request.PathInfo.Length == 0 ? string.Empty :
            context.Request.PathInfo.Substring(1);

        switch (resource.ToLower(CultureInfo.InvariantCulture))
        {
            case "detail" :
                return new ErrorDetailPage();

            case "html" :
                return new ErrorHtmlPage();

            case "rss" :
                return new ErrorRssHandler();

            default :
                return new ErrorLogPage();
        }
    }
}

Comme vous pouvez le voir, la méthode de GetHandler() la ErrorLogPageFactory classe retourne un gestionnaire HTTP instance basé sur le PathInfo de la requête. Si a la PathInfo valeur rss, une instance du ErrorRssHandler gestionnaire HTTP est retournée, ce qui restitue le journal sous la forme d’un flux RSS. Si a la PathInfo valeur detail, un ErrorDetailPage gestionnaire HTTP instance est retourné, qui affiche des informations sur une exception particulière.

Dans les paramètres de l’application web ASP.NET, vous devez spécifier un chemin d’accès mappé à la fabrique de ErrorLogPageFactory gestionnaire HTTP, par ErrorLog.aspxexemple . Pour afficher un flux RSS du journal des exceptions, vous pouvez visiter : http://www.example.com/ErrorLog.aspx/rss.

Les différentes classes de gestionnaire HTTP d’ELMAH (ErrorDetailPage , ErrorRssHandlerErrorHtmlPageErrorLogPageetc.) affichent des marques différentes. Le ErrorRssHandler gestionnaire HTTP, pour instance, effectue une boucle sur les 15 dernières erreurs et émet le balisage XML approprié pour afficher ces informations dans un format RSS. Les autres gestionnaires HTTP sont tous dérivés, directement ou indirectement, de la System.Web.UI.Page classe (qui est la classe à partir de laquelle toutes les classes code-behind ASP.NET sont dérivées). Ces gestionnaires HTTP liés à la page remplacent les méthodes Render() et OnLoad() de la Page classe pour créer une interface HTML affichant une liste paginable des exceptions journalisées. Reportez-vous aux figures 1, 2 et 3 pour obtenir des captures d’écran de ces pages.

Note Alors que la Error classe enregistre les ServerVariablescollections , QueryString, Formet Cookie , seule la ServerVariables collection est affichée dans les détails d’une exception. Cela est dû au fait que les QueryString paramètres et les cookies sont visibles via les ServerVariableparamètres et QUERY_STRINGHTTP_COOKIE , respectivement. La Form collection est omise, car elle peut inclure potentiellement des dizaines de kilo-octets d’informations d’état d’affichage qui ne servent généralement qu’à peu d’utilité pour la plupart des diagnostics. Bien sûr, vous pouvez facilement modifier les détails du gestionnaire HTTP pour inclure ces informations, si vous le souhaitez.

Maintenant que nous avons examiné les trois sous-systèmes d’ELMAH, voyons comment ajouter ELMAH à une application web ASP.NET existante. Prêtez une attention particulière à la facilité d’ajout d’ELMAH à n’importe quel site, un avantage de la composantisation que les gestionnaires et modules HTTP offrent.

Ajout d’ELMAH à une application web ASP.NET

L’ajout d’ELMAH à une application web ASP.NET est assez simple et comprend deux étapes :

  • Ajout de l’assembly ELMAH à l’application web.
  • Configuration de l’application web pour utiliser les modules HTTP et les gestionnaires HTTP d’ELMAH.

ELMAH peut être appliqué à une application web particulière sur un serveur Web en copiant l’assembly dans le répertoire de /bin l’application web et en configurant les paramètres d’ELMAH via le Web.config fichier. De plus, vous pouvez configurer ELMAH pour qu’il soit appliqué à toutes les applications web sur un serveur Web en ajoutant l’assembly au Global Assembly Cache (GAC) du serveur Web et en ajoutant les mêmes paramètres de configuration à machine.config la place de Web.config.

Dans le Web.config fichier (ou machine.config), vous devez ajouter les paramètres suivants :

  • Élément <sectionGroup> dans l’élément configSections> qui définit un nouveau nom de section, , avec une section à l’intérieur appelée , qui contient des informations sur la< façon de journaliser les informations d’exception.<errorLog><gotdotnet.elmah>
  • Une <gotdotnet.elmah> section, avec une section interne nommée <errorLog>, qui contient une référence de type à l’enregistreur d’événements d’exceptions que vous souhaitez qu’ELMAH utilise, ainsi que tous les paramètres spécifiques à cet enregistreur d’événements d’exceptions.
  • Entrée de la <httpHandlers> section indiquant le chemin d’accès qui, lorsqu’il est visité via un navigateur, affiche différents affichages dans le journal des erreurs.
  • Entrée dans la <httpModules> section qui ajoute au ErrorLogModule pipeline HTTP ASP.NET.

L’extrait de code suivant du fichier inclus dans le Web.config téléchargement de cet article illustre comment ces quatre paramètres peuvent être spécifiés :

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <!-- Allows for a new section group to the Web.config -->
    <sectionGroup name="gotdotnet.elmah">
      <!-- Indicates that inside the section group there will be an
              errorLog section -->
      <section name="errorLog" 
        type="System.Configuration.SingleTagSectionHandler, 
          System, Version=1.0.5000.0, Culture=neutral, 
          PublicKeyToken=b77a5c561934e089" />
    </sectionGroup>
  </configSections>

  <!-- This section group contains the type of the exception logger
         to use (SqlErrorLog, MemoryErrorLog, or a custom logger).
         It also contain properties pertinent to the exception logger
         (connectionString, for the SqlErrorLog). -->
  <gotdotnet.elmah>
    <errorLog type="GotDotNet.Elmah.SqlErrorLog, 
      GotDotNet.Elmah, Version=1.0.5527.0, Culture=neutral, 
      PublicKeyToken=978d5e1bd64b33e5" 
      connectionString="...connection string..." />
  </gotdotnet.elmah>

  <system.web>
    <!-- Register that a request to aspnetham/errorlog.aspx should
        be serviced by the ErrorLogPageFactory HTTP Handler factory -->
    <httpHandlers>
      <add verb="POST,GET,HEAD" path="elmah/default.aspx" 
        type="GotDotNet.Elmah.ErrorLogPageFactory, 
        Skybow.Samples.AspNetHam, Version=1.0.5527.0, 
        Culture=neutral, PublicKeyToken=978d5e1bd64b33e5" />
    </httpHandlers>

    <!-- Adds the ErrorLogModule HTTP Module to the HTTP pipeline. -->
    <httpModules>
      <add name="ErrorLog" type="GotDotNet.Elmah.ErrorLogModule, 
         GotDotNet.Elmah, Version=1.0.5527.0, Culture=neutral, 
         PublicKeyToken=978d5e1bd64b33e5" />
    </httpModules>
    
    ...
  </system.web>
</configuration>

L’élément <sectionGroup> dans l’élément <configSections> indique qu’il y aura un groupe de sections supplémentaire dans le fichier de configuration appelé <gotdotnet.elmah>. En outre, il indique qu’à l’intérieur de cette section personnalisée, il y aura une <errorLog> section. À l’intérieur de l’élément réel <gotdotnet.elmah> se trouve un <errorLog> élément qui spécifie l’implémentation du journal des erreurs à utiliser. Rappelez-vous qu’ELMAH est fourni avec deux implémentations intégrées, à savoir SqlErrorLog et MemoryErrorLog. Vous pouvez spécifier lequel de ces deux éléments utiliser, ou vous pouvez spécifier pour utiliser un journal d’exceptions personnalisé que vous avez peut-être créé, dans l’élément <errorLog> . L’élément <errorLog> contient également les paramètres spécifiques à une implémentation du journal des erreurs. Par exemple, lors de l’utilisation de l’élément <errorLog> pour indiquer que doit SqlErrorLog être utilisé, une connectionString propriété doit être incluse qui lui indique comment se connecter à la base de données. Le script SQL permettant de créer la table appropriée et les procédures stockées associées sont inclus dans le téléchargement.

Note Si vous souhaitez qu’un administrateur soit envoyé par courrier électronique en cas d’exception non gérée, vous devez ajouter un autre <section> élément dans <sectionGroup> qui définit un nouvel élément appelé <errorMail>. En outre, dans l’élément réel <gotdotnet.elmah> , vous devez ajouter un <errorMail> élément . Consultez le Web.config fichier dans le téléchargement pour obtenir un exemple de cette syntaxe.

La <httpHandlers> section spécifie que ( ErrorLogPageFactory une fabrique de gestionnaire HTTP) doit être utilisé pour récupérer le gestionnaire HTTP qui restitue le contenu pour afficher le journal des erreurs. La valeur de l’attribut path indique l’URL relative à la racine virtuelle de l’application pour accéder à l’affichage du journal des erreurs. Vous pouvez le remplacer par ce que vous voulez, mais assurez-vous qu’il s’agit d’une URL avec une extension qui est gérée par le moteur de ASP.NET. Autrement dit, si vous remplacez le chemin par quelque chose comme errors.log, vous devez configurer IIS pour mapper les requêtes à errors.log l’extension ISAPI ASP.NET (aspnet_isapi.dll). Si vous souhaitez vous assurer que seuls les administrateurs peuvent afficher le journal, utilisez ASP. Fonctionnalités d’autorisation d’URL de NET pour restreindre l’accès à un utilisateur spécifique ou à un ensemble d’utilisateurs ou de rôles. En revanche, si vous souhaitez désactiver entièrement l’accès web au journal, vous ne configurez simplement pas la <httpHandlers> section.

La <httpModules> section ajoute le ErrorLogModule module HTTP au pipeline HTTP ASP.NET. Veillez à inclure ce <httpModules> paramètre, sinon ELMAH n’écoute pas l’événement Error et ne journalisera donc pas d’exceptions non gérées.

Comme vous pouvez le voir, l’ajout d’ELMAH à une application web ASP.NET existante est assez simple. Le déploiement et la réutilisation simples d’ELMAH sont dus au fait qu’il est composant à l’aide de modules et de gestionnaires HTTP.

Conclusion

Nous espérons que cet article a été en mesure de mettre en lumière la façon dont les gestionnaires et modules HTTP sont d’excellents outils pour la création de fonctionnalités orthogonales dans une application web ASP.NET. Les tâches courantes telles que la journalisation centralisée à l’échelle de l’application ou la supervision des demandes sur l’ensemble de l’application peuvent être composantées via des gestionnaires et des modules. En récapsulant cette fonctionnalité dans un ensemble de composants, vous bénéficiez d’avantages en matière de réutilisation, de facilité de maintenance et de déploiement sans nécessiter de migration, d’intégration ou de recompilation du code et des applications existants.

Pour illustrer la création de composants possible avec des modules et des gestionnaires HTTP, nous avons examiné ELMAH, une application centralisée de journalisation et de publipostage des erreurs. ELMAH utilise un module HTTP pour écouter tous les événements à l’échelle Error de l’application, qui est déclenché à la suite d’une exception non gérée qui se déclenche. Lors de l’apprentissage d’une exception non gérée, ELMAH enregistre l’exception dans une base de données SQL Server, dans la mémoire ou, peut-être, dans un autre magasin de stockage. ELMAH peut également envoyer par e-mail le contenu de l’exception à un ou plusieurs destinataires tels que les développeurs et le personnel des opérations.

En plus d’un module HTTP, ELMAH contient un ensemble de gestionnaires HTTP et une fabrique de gestionnaires HTTP pour faciliter l’affichage du journal des erreurs via un support web. Cela inclut non seulement une page Web traditionnelle, mais également un flux RSS. ELMAH gère un composant discret en faisant en sorte que la fonctionnalité d’affichage soit encapsulée dans un gestionnaire HTTP, au lieu d’exiger que l’application Web inclue une page Web ASP.NET qui affiche ces informations. Grâce à l’utilisation de gestionnaires HTTP, le déploiement d’ELMAH est un processus simple qui ne nécessite pas de recompilation de l’application web ou de chargement d’une page Web ASP.NET sur le serveur de production.

ELMAH n’est qu’un exemple de la puissance de la componentisation offerte par les gestionnaires et modules HTTP. Il existe peut-être d’autres processus à l’échelle de l’application que vous avez implémentés qui peuvent tirer parti de la création de composants avec des gestionnaires et des modules.

Bonne programmation!

Remerciements

Avant de soumettre cet article à l’éditeur MSDN, un certain nombre de bénévoles nous ont aidés à relire l’article et à fournir des commentaires sur le contenu, la grammaire et la direction de l’article. Les principaux contributeurs au processus de révision de cet article sont Milan Negovan, Carl Lambrecht, Dominique Kuster, Roman Mathis, Raffael Zaghet, Muhammad Abubakar et Patrick Schuler.

Références

Atif Aziz a près de 13 ans d’expérience dans le développement de solutions sur la plateforme Microsoft. Il est consultant principal chez Skybow AG, où son objectif principal est d’aider les clients à comprendre et à créer des solutions sur la plateforme de développement .NET. Atif contribue régulièrement à la communauté des développeurs Microsoft en donnant des conférences microsoft et non-Microsoft et en écrivant des articles pour des publications techniques. Il est conférencier à l’INETA et président du plus grand groupe d’utilisateurs .NET suisse (dotMUGS). Il peut être joint à l’adresse atif.aziz@skybow.com ou via son site Web à l’adresse http://www.raboof.com.

Scott Mitchell, auteur de cinq livres ASP/ASP.NET et fondateur de 4GuysFromRolla.com, travaille avec les technologies Web Microsoft depuis 1998. Scott travaille comme consultant indépendant, formateur et écrivain. On peut le joindre sur mitchell@4guysfromrolla.com ou via son blog, qui se trouve à l’adresse http://ScottOnWriting.NET.

© Microsoft Corporation. Tous droits réservés.