Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0

Article
10/22/2014

Mise à jour : novembre 2007

Cette rubrique décrit le cycle de vie des applications ASP.NET. Elle en répertorie les événements importants et décrit la façon dont le code que vous écrivez peut s'y intégrer. Les informations contenues dans cette rubrique s'appliquent à IIS 5.0 et IIS 6.0. Pour plus d'informations sur le cycle de vie des applications ASP.NET dans IIS 7.0, consultez Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 7.0.

Dans ASP.NET, plusieurs étapes de traitement doivent avoir lieu pour qu'une application ASP.NET soit initialisée et puisse traiter des demandes. En outre, ASP.NET n'est qu'une partie de l'architecture de serveur Web qui entretient les demandes soumises par les navigateurs. Il est important que vous compreniez le cycle de vie de l'application afin pouvoir écrire le code à l'étape précise du cycle de vie correspondant à l'effet que vous comptez obtenir.

Cycle de vie d'une application en général

Le tableau suivant décrit les étapes du cycle de vie de l'application ASP.NET.

Étape	Description
L'utilisateur demande une ressource d'application au serveur Web.	Le cycle de vie d'une application ASP.NET commence par une demande soumise par un navigateur au serveur Web (pour les applications ASP.NET, en général IIS). ASP.NET est une extension ISAPI sous le serveur Web. Lorsqu'un serveur Web reçoit une demande, il examine l'extension de nom du fichier demandé, détermine quelle extension ISAPI doit gérer la demande, puis transmet cette demande à l'extension ISAPI appropriée. ASP.NET gère les extensions de nom de fichier qui lui ont été mappées, telles que .aspx, .ascx, .ashx et .asmx. Remarque : Si une extension de nom de fichier n'a pas été mappée à ASP.NET, ASP.NET ne recevra pas la demande. Ce point est important à comprendre s'agissant des applications qui utilisent l'authentification ASP.NET. Par exemple, ASP.NET ne vérifiera pas l'authentification ou l'autorisation des demandes s'agissant de fichiers .htm, les fichiers .htm n'étant en général pas mappés à ASP.NET. Par conséquent, même si un fichier ne contient que du contenu statique, si vous souhaitez qu'ASP.NET vérifie l'authentification, créez le fichier en lui donnant une extension de nom de fichier mappée à ASP.NET, telle que .aspx. Remarque : Si vous créez un gestionnaire personnalisé pour servir une extension de nom de fichier particulière, vous devez mapper cette extension à ASP.NET dans IIS et enregistrer également le gestionnaire dans le fichier Web.config de votre application. Pour plus d'informations, consultez Vue d'ensemble des gestionnaires HTTP et des modules HTTP.
ASP.NET reçoit la première demande concernant l'application.	Lorsque ASP.NET reçoit la première demande de ressource dans une application, une classe nommée ApplicationManager crée un domaine d'application. Les domaines d'application permettent d'isoler les applications entre elles pour les variables globales et autorisent chaque application à être déchargée séparément. Au sein d'un domaine d'application, une instance de la classe nommée HostingEnvironment est créée, afin de donner accès à des informations sur l'application, par exemple le nom du dossier où celle-ci est stockée. Le diagramme suivant illustre cette relation : ASP.NET compile également, si besoin est, les éléments de niveau supérieur de l'application, notamment le code d'application dans le dossier App_Code. Pour plus d'informations, consultez ultérieurement « Cycle de vie de compilation » plus loin dans cette rubrique.
Les objets principaux d'ASP.NET sont créés à chaque demande.	Une fois le domaine d'application créé et l'objet HostingEnvironment instancié, ASP.NET crée et initialise des objets principaux tels que HttpContext, HttpRequest et HttpResponse. La classe HttpContext contient des objets spécifiques à la demande d'application actuelle, tels que les objets HttpRequest et HttpResponse. L'objet HttpRequest contient des informations sur la demande actuelle, notamment des informations de cookies et de navigateur. L'objet HttpResponse contient la réponse envoyée au client, notamment la totalité du flux de sortie à restituer et des cookies.
Un objet HttpApplication est assigné à la demande	Une fois que tous les objets d'application principaux sont initialisés, l'application est démarrée en créant une instance de la classe HttpApplication. Si l'application possède un fichier Global.asax, ASP.NET crée à la place de ce fichier une instance de la classe Global.asax dérivée de la classe HttpApplication et utilise la classe dérivée pour représenter l'application. Remarque : La première fois qu'une page ou un processus ASP.NET est demandé dans une application, une nouvelle instance de HttpApplication est créée. Toutefois, les instances de HttpApplication peuvent être réutilisées pour plusieurs demandes afin d'améliorer les performances. Lorsqu'une instance de HttpApplication est créée, les modules configurés sont également créés. Par exemple, si l'application est configurée pour cela, ASP.NET crée un module SessionStateModule. Une fois que tous les modules configurés ont été créés, la méthode Init de la classe HttpApplication est appelée. Le diagramme suivant illustre cette relation :
La demande est traitée par le pipeline HttpApplication.	Les événements suivants sont exécutés par la classe HttpApplication pendant le traitement de la demande. Ils sont d'un grand intérêt pour les développeurs qui souhaitent étendre la classe HttpApplication. Validez la demande, ce qui fait examiner les informations envoyées par le navigateur et déterminer si elles contiennent un balisage potentiellement malveillant. Pour plus d'informations, consultez ValidateRequest et Vue d'ensemble des attaques de script. Exécutez le mappage d'URL, si des URL ont été configurées dans la section UrlMappingsSection du fichier Web.config. Déclenchez l'événement BeginRequest. Déclenchez l'événement AuthenticateRequest. Déclenchez l'événement PostAuthenticateRequest. Déclenchez l'événement AuthorizeRequest. Déclenchez l'événement PostAuthorizeRequest. Déclenchez l'événement ResolveRequestCache. Déclenchez l'événement PostResolveRequestCache. En fonction de l'extension de nom de fichier de la ressource demandée (mappée dans le fichier de configuration de l'application), sélectionnez une classe qui implémente IHttpHandler pour traiter la demande. Si la demande concerne un objet (page) dérivé de la classe Page et si la page doit être compilée, ASP.NET compile la page avant d'en créer une instance. Déclenchez l'événement PostMapRequestHandler. Déclenchez l'événement AcquireRequestState. Déclenchez l'événement PostAcquireRequestState. Déclenchez l'événement PreRequestHandlerExecute. Appelez la méthode ProcessRequest (ou la version asynchrone IHttpAsyncHandler.BeginProcessRequest) de la classe IHttpHandler appropriée à la demande. Par exemple, si la demande concerne une page, l'instance de la page actuelle gérera la demande. Déclenchez l'événement PostRequestHandlerExecute. Déclenchez l'événement ReleaseRequestState. Déclenchez l'événement PostReleaseRequestState. Exécutez le filtrage de réponse si la propriété Filter est définie. Déclenchez l'événement UpdateRequestCache. Déclenchez l'événement PostUpdateRequestCache. Déclenchez l'événement EndRequest. Déclenchez l'événement PreSendRequestHeaders. Déclenchez l'événement PreSendRequestContent.

Événements de cycle de vie et fichier Global.asax

Au cours de son cycle de vie, l'application déclenche des événements que vous pouvez gérer et appelle des méthodes spécifiques que vous pouvez substituer. Pour gérer des événements ou des méthodes d'application, vous pouvez créer un fichier nommé Global.asax dans le répertoire racine de votre application.

Si vous créez un fichier Global.asax, ASP.NET le compile en une classe dérivée de la classe HttpApplication, puis utilise la classe dérivée pour représenter l'application.

Une instance de HttpApplication ne traite qu'une demande à la fois. Cela simplifie la gestion d'événements d'application, puisque vous n'avez pas besoin de verrouiller les membres non statiques de la classe d'application lorsque vous y accédez. Cela vous permet également de stocker des données spécifiques à la demande dans les membres non statiques de la classe d'application. Par exemple, vous pouvez définir une propriété dans le fichier Global.asax et lui assigner une valeur spécifique à la demande.

ASP.NET lie automatiquement des événements d'application à des gestionnaires dans le fichier Global.asax à l'aide de la convention d'affectation de noms Application_événement, par exemple Application_BeginRequest. Cela est comparable à la façon dont les méthodes de page ASP.NET sont automatiquement liées à des événements, comme l'événement Page_Load de la page. Pour plus d'informations, consultez Vue d'ensemble du cycle de vie des pages ASP.NET.

Les méthodes Application_Start et Application_End sont des méthodes spéciales qui ne représentent pas d'événements HttpApplication. ASP.NET les appelle une fois dans toute la durée de vie du domaine d'application, et non pour chaque instance de HttpApplication.

Le tableau suivant répertorie quelques-uns des événements et méthodes utilisés au cours du cycle de vie de l'application. Il existe beaucoup plus d'événements que ceux qui sont répertoriés, mais leur utilisation n'est pas courante.

Événement ou méthode	Description
Application_Start	Appelé lorsque la première ressource (par exemple une page) d'une application ASP.NET est demandée. La méthode Application_Start n'est appelée qu'une fois au cours du cycle de vie d'une application. Vous pouvez utiliser cette méthode pour effectuer des tâches de démarrage telles que le chargement de données dans le cache ou l'initialisation de valeurs statiques. Les données statiques ne doivent être définies qu'au démarrage de l'application. Ne définissez pas de données d'instance parce qu'elles ne seront disponibles que pour la première instance de la classe HttpApplication créée.
Application_event	Déclenché au moment approprié du cycle de vie de l'application, comme le montre la table des cycles de vie de l'application, vue précédemment dans cette rubrique. Application_Error peut être déclenché à tout moment du cycle de vie de l'application. Application_EndRequest est le seul événement qui sera déclenché à coup sûr à chaque demande, parce qu'une demande peut être court-circuitée. Par exemple, si deux modules gèrent l'événement Application_BeginRequest et si le premier lève une exception, l'événement Application_BeginRequest ne sera pas appelé pour le deuxième module. Toutefois, la méthode Application_EndRequest est toujours appelée pour autoriser l'application à nettoyer les ressources.
Init	Demandé une fois pour chaque instance de la classe HttpApplication une fois que tous les modules ont été créés.
Dispose	Appelé avant que l'instance d'application ne soit détruite. Vous pouvez utiliser cette méthode pour libérer manuellement toutes les ressources non managées. Pour plus d'informations, consultez Nettoyage de ressources non managées.
Application_End	Appelé une fois dans la durée de vie de l'application avant que celle-ci ne soit déchargée.

Cycle de vie de compilation

Lorsque la première demande est envoyée à une application, ASP.NET compile les éléments d'application dans un ordre spécifique. Les premiers éléments à être compilés sont appelés éléments de niveau supérieur. Après la première demande, les éléments de niveau supérieur ne sont recompilés que si une dépendance change. Le tableau suivant décrit l'ordre dans lequel les éléments de niveau supérieur d'ASP.NET sont compilés.

Élément	Description
App_GlobalResources	Les ressources globales de l'application sont compilées et un assembly de ressource est construit. Tous les assemblys du dossier Bin de l'application sont liés à l'assembly de ressource.
App_WebResources	Les types de proxys des services Web sont créés et compilés. L'assembly de références Web obtenu est lié à l'assembly de ressource s'il existe.
Propriétés de profil définies dans le fichier Web.config	Si les propriétés de profil sont définies dans le fichier Web.config de l'application, un assembly est généré et contient un objet de profil.
App_Code	Les fichiers de code source sont générés et un ou plusieurs assemblys sont créés. Tous les assemblys de code et l'assembly de profil sont liés aux assemblys de ressources et de références Web, le cas échéant.
Global.asax	L'objet d'application est compilé et lié à tous les assemblys générés précédemment.

Une fois que les éléments de niveau supérieur de l'application ont été compilés, ASP.NET compile les dossiers, les pages et les autres éléments en fonction des besoins. Le tableau suivant décrit l'ordre dans lequel les dossiers et les éléments d'ASP.NET sont compilés.

Élément	Description
App_LocalResources	Si le dossier qui contient l'élément demandé contient un dossier App_LocalResources, le contenu du dossier de ressources local est compilé et lié à l'assembly de ressources globales.
Pages Web individuelles (fichiers .aspx), contrôles utilisateur (fichiers .ascx), gestionnaires HTTP (fichiers .ashx) et modules HTTP (fichiers .asmx)	Compilés en fonction des besoins et liés à l'assembly de ressources local et aux assemblys de niveau supérieur.
Thèmes, pages maîtres, autres fichiers sources	Les fichiers d'apparence pour les thèmes individuels, les pages maîtres et les autres fichiers de code source référencés par les pages sont compilés au moment où la page qui référence est compilée.

Les assemblys compilés sont mis en cache sur le serveur et réutilisés pour les demandes suivantes et ils sont conservés à chaque redémarrage de l'application tant que le code source reste inchangé.

L'application étant compilée à la première demande, la demande initiale envoyée à une application peut être beaucoup plus longue que les demandes suivantes. Vous pouvez précompiler votre application pour réduire la durée de la première demande. Pour plus d'informations, consultez Comment : précompiler des sites Web ASP.NET.

Redémarrages de l'application

À cause de la modification du code source de votre application Web, ASP.NET recompile les fichiers sources dans des assemblys. Lorsque vous modifiez les éléments de niveau supérieur de votre application, tous les autres assemblys de l'application qui référencent les assemblys de niveau supérieur sont également recompilés.

De plus, la modification, l'ajout ou la suppression de certains types de fichiers dans les dossiers connus de l'application provoque le redémarrage de l'application. Les actions suivantes provoqueront un redémarrage de l'application :

Ajout, modification ou suppression d'assemblys du dossier Bin de l'application.
Ajout, modification ou suppression de ressources de localisation des dossiers App_GlobalResources ou App_LocalResources.
Ajout, modification ou suppression du fichier Global.asax de l'application.
Ajout, modification ou suppression de fichiers de code source dans le répertoire App_Code.
Ajout, modification ou suppression de la configuration du profil.
Ajout, modification ou suppression des références de service Web dans le répertoire App_WebReferences.
Ajout, modification ou suppression du fichier Web.config de l'application.

Lorsqu'un redémarrage de l'application est requis, ASP.NET traite toutes les demandes en attente du domaine d'application existant et les assemblys anciens avant de redémarrer le domaine d'application et de charger les nouveaux assemblys.

Modules HTTP

Le cycle de vie de l'application ASP.NET est extensible via les classes IHttpModule. ASP.NET comprend plusieurs classes qui implémentent IHttpModule, telles que la classe SessionStateModule. Vous pouvez également créer vos propres classes qui implémentent IHttpModule.

Si vous ajoutez des modules à votre application, ces derniers peuvent eux-mêmes déclencher des événements. L'application peut s'abonner à ces événements dans le fichier Global.asax en utilisant la convention NomModule_NomÉvénement. Par exemple, pour gérer l'événement Authenticate déclenché par un objet FormsAuthenticationModule, vous pouvez créer un gestionnaire nommé FormsAuthentication_Authenticate.

La classe SessionStateModule est activée par défaut dans ASP.NET. Tous les événements de session sont automatiquement rattachés en tant Session_événement, tel que Session_Start. L'événement Start est déclenché chaque fois qu'une nouvelle session est créée. Pour plus d'informations, consultez Vue d'ensemble de l'état de session ASP.NET.