Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 7.0
Mise à jour : novembre 2007
Cette rubrique décrit le cycle de vie de l'application pour les applications ASP.NET qui s'exécutent dans IIS 7.0 en mode intégré et avec le .NET Framework 3.0 ou version ultérieure. IIS 7.0 prend également en charge le mode classique, qui se comporte comme ASP.NET s'exécutant sous IIS 6.0. Pour plus d'informations, consultez Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0.
Le pipeline intégré d'IIS 7.0 est un pipeline de traitement des demandes unifié qui prend en charge à la fois les modules de code natif et les modules de code managé. Les modules de code managé qui implémentent l'interface IHttpModule ont accès à tous les événements du pipeline de demande. Par exemple, un module de code managé peut être utilisé pour l'authentification par formulaire ASP.NET à la fois pour les pages Web ASP.NET (fichiers .aspx) et pour les pages HTML (fichiers .htm ou .html). Ceci est vrai bien que les pages HTML soient traitées comme des ressources statiques par IIS et ASP.NET. Pour plus d'informations sur IIS 7.0 en mode intégré, consultez ASP.NET Integration with IIS7.
Cette rubrique contient les sections suivantes :
Vue d'ensemble de l'architecture
Étapes du cycle de vie
Utilisation du fichier Global.asax
Modules de code managé dans IIS 7.0
Vue d'ensemble de l'architecture
Dans IIS 7.0 mode intégré, une demande passe par différentes étapes similaires aux étapes des demandes de ressources ASP.NET dans IIS 6.0. Toutefois, dans IIS 7.0, ces étapes incluent plusieurs événements d'application supplémentaires, tels que les événements MapRequestHandler, LogRequest et PostLogRequest.
La principale différences entre IIS 7.0 et IIS 6.0 concernant les étapes de traitement réside dans la manière dont ASP.NET est intégré au serveur IIS. Dans IIS 6.0, il y a deux pipelines de traitement des demandes : l'un destiné aux filtres ISAPI de code natif et aux composants d'extension, et l'autre aux composants d'application de code managé, tels qu'ASP.NET. Dans IIS 7.0, le runtime ASP.NET est intégré au serveur Web de sorte qu'il existe un seul pipeline de traitement de demandes unifié pour toutes les demandes. Pour les développeurs ASP.NET, les avantages du pipeline intégré sont les suivants :
Le pipeline intégré déclenche tous les événements exposés par l'objet HttpApplication, qui permet aux modules HTTP ASP.NET existants de fonctionner dans IIS 7.0 en mode intégré.
Les modules de code natif et les modules de code managé sont configurés au niveau du serveur Web, du site Web ou de l'application Web. Ceci inclut les modules de code managé ASP.NET intégrés pour la gestion de l'état de session, de l'authentification par formulaire, des profils et des rôles. De plus, les modules de code managé peuvent être activés ou désactivés pour toutes les demandes, que la demande porte ou non sur une ressource ASP.NET, comme un fichier .aspx.
Les modules de code managé peuvent être appelés à toute étape dans le pipeline : avant tout traitement serveur de la demande, après l'intégralité du traitement serveur ou à toute étape intermédiaire.
Vous pouvez inscrire et activer ou désactiver des modules par le biais du fichier Web.config d'une application.
L'illustration suivante montre la configuration du pipeline de demande d'une application. Cet exemple inclut les éléments suivants :
Le module de code natif Anonymous et le module de code natif Forms (qui correspond à FormsAuthenticationModule). Ces modules sont configurés et ils sont appelés durant l'étape Authentication de la demande.
Le module de code natif Basic et le module de code natif Windows (qui correspond à WindowsAuthenticationModule). Ils sont représentés, mais ne sont pas configurés pour l'application.
L'étape Execute handler, dans laquelle le gestionnaire (module dont la portée est limitée à un URL) est appelé pour construire la réponse. Pour les fichiers .aspx files, le gestionnaire PageHandlerFactory est utilisé pour répondre à la demande. Pour les fichiers statiques, le module StaticFileModule de code natif répond à la demande.
Le module de code natif Trace. Ce module est représenté, mais il n'est pas configuré pour l'application.
La classe de code managé Custom module. Cette classe est appelée durant l'étape Log request.
.png)
Pour plus d'informations sur les problèmes de compatibilité connus avec les applications ASP.NET à partir desquelles est effectuée la migration des versions antérieures d'IIS vers IIS 7.0, consultez la section « Known Differences Between Integrated Mode and Classic Mode » de la rubrique Upgrading ASP.NET Applications to IIS 7.0: Differences between IIS 7.0 Integrated Mode and Classic mode.
Étapes du cycle de vie
Le tableau suivant répertorie les étapes du cycle de vie d'application ASP.NET avec le mode intégré dans IIS 7.0.
Étape |
Description |
|---|---|
Une demande de ressource d'application est émise. |
Le cycle de vie d'une application ASP.NET démarre par une demande envoyée par un navigateur au serveur Web. En mode classique dans IIS 7.0 et dans IIS 6.0, le pipeline de demande ASP.NET est distinct du pipeline de serveur Web. Les modules s'appliquent uniquement aux demandes routées vers l'extension ISAPI ASP.NET. Si l'extension de nom de fichier du type de ressource demandée n'est pas mappée explicitement à ASP.NET, les fonctionnalités ASP.NET ne sont pas appelées pour la demande, car la demande n'est pas traitée par le runtime ASP.NET. En mode intégré dans IIS 7.0, un pipeline unifié gère toutes les demandes. Lorsque le pipeline intégré reçoit une demande, la demande passe par des étapes qui sont communes à toutes les demandes. Ces étapes sont représentées par l'énumération RequestNotification. Toutes les demandes peuvent être configurées pour tirer parti de fonctionnalités ASP.NET, car ces fonctionnalités sont encapsulées dans les modules de code managé qui ont accès au pipeline de demande. Par exemple, bien que l'extension de nom de fichier .htm ne soit pas mappé explicitement à ASP.NET, une demande de page HTML appelle des modules ASP.NET. Cela vous permet de tirer parti de l'authentification et de l'autorisation ASP.NET pour toutes les ressources. |
Le pipeline unifié reçoit la première demande pour l'application. |
Lorsque le pipeline unifié reçoit la première demande pour toute ressource dans une application, une instance de la classe ApplicationManager est créée, qui est le domaine d'application dans lequel la demande est traitée. Les domaines d'application fournissent l'isolation entre les applications pour les variables globales et permettent à chaque application d'être déchargée séparément. Au sein du domaine d'application, une instance de la classe 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. Pendant la première demande, les éléments de niveau supérieur dans l'application sont compilés si nécessaire. Ceci inclut le code d'application contenu dans le dossier App_Code. Vous pouvez inclure des modules et des gestionnaires personnalisés dans le dossier App_Code comme décrit plus bas dans la section Modules de code managé dans IIS 7.0 de cette rubrique. |
Des objets de réponse sont créés pour chaque demande. |
Une fois le domaine d'application créé et l'objet HostingEnvironment instancié, des objets d'application tels que HttpContext, HttpRequest et HttpResponse sont créés et initialisés. 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. Les principales différences entre IIS 6.0 et IIS 7.0 s'exécutant en mode intégré et le .NET Framework 3.0 ou version ultérieure incluent les différences suivantes :
|
Un objet HttpApplication est assigné à la demande |
Une fois que tous les objets d'application sont initialisés, l'application est démarrée par la création d'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. .gif "Remarque") Remarque :
La première fois qu'une page ou un processus ASP.NET est demandé dans une application, une nouvelle instance de la classe HttpApplication est créée. Toutefois, les instances de HttpApplication peuvent être réutilisées pour plusieurs demandes afin d'améliorer les performances.
Les modules ASP.NET chargés (tel que le SessionStateModule) sont déterminés par les modules de code managé dont l'application hérite d'une application parente. Ils sont également déterminés par les modules qui sont configurés dans la section de configuration du fichier Web.config de l'application. Les modules sont ajoutés ou supprimés dans l'élément modules Web.config de l'application dans la section system.webServer. Pour plus d'informations, consultez Comment : configurer la section <system.webServer> pour IIS 7.0. |
La demande est traitée par le pipeline HttpApplication. |
Les tâches suivantes sont effectuées par la classe HttpApplication lors du traitement de la demande. Les événements sont utiles pour les développeurs de pages qui souhaitent exécuter du code lorsque des événements clés de pipeline de demande sont déclenchés. Ils sont également utiles si vous développez un module personnalisé et que vous souhaitiez que le module soit appelé pour toutes les demandes envoyées au pipeline. Les modules personnalisés implémentent l'interface IHttpModule. En mode intégré dans IIS 7.0, vous devez enregistrer des gestionnaires d'événements dans la méthode Init d'un module.
|
Utilisation du fichier Global.asax
Le fichier Global.asax est autant utilisé en mode Intégré dans IIS 7.0 que dans ASP.NET dans IIS 6.0. Pour plus d'informations, consultez "Événements du cycle de vie et fichier Global.asax" dans Vue d'ensemble du cycle de vie des applications ASP.NET pour IIS 5.0 et 6.0.
L'une des différences est que vous pouvez ajouter des gestionnaires pour les événements MapRequestHandler, LogRequest et PostLogRequest. Ces événements sont pris en charge pour les applications qui s'exécutent en mode intégré dans IIS 7.0 et avec le .NET Framework 3.0 ou version ultérieure.
Vous pouvez fournir des gestionnaires d'événements d'application dans le fichier Global.asax pour ajouter du code qui s'exécute pour toutes les demandes gérées par ASP.NET, telles que les demandes de pages .aspx et .axd. Toutefois, le code de gestionnaire dans le fichier Global.asax n'est pas appelé pour les demandes de ressources non-ASP.NET, telles que les fichiers statiques. Pour exécuter du code managé qui s'exécute pour toutes les ressources, créez un module personnalisé qui implémente l'interface IHttpModule. Le module personnalisé s'exécutera pour toutes les demandes de ressources dans l'application, même si le gestionnaire de ressources n'est pas un gestionnaire ASP.NET.
Modules de code managé dans IIS 7.0
Les modules de code managé ASP.NET pouvant être configurés et chargés dans IIS 7.0 incluent les modules suivants :
Pour configurer les modules de code managé IIS 7.0, vous pouvez utiliser l'une des méthodes suivantes :
Utilisez Gestionnaire des services IIS. Pour plus d'informations, consultez Comment : ouvrir le Gestionnaire des services IIS.
Utilisation de l'outil de ligne de commande IIS 7.0 (Appcmd.exe). Pour plus d'informations, consultez IIS 7.0 Command-Line Tool.
Modifiez le magasin de configuration XML d'IIS 7.0. Pour plus d'informations, consultez IIS 7.0: IIS 7.0 Configuration Store.
Lorsqu'un module de code managé ASP.NET tel que le module FormsAuthenticationModule, est configuré pour se charger dans IIS 7.0, il a accès à tous les événements contenus dans le pipeline de demande. Cela signifie que toutes les demandes passent par le module de code managé. Pour la classe FormsAuthenticationModule, cela signifie que le contenu statique peut être protégé par l'authentification par formulaire, bien que le contenu ne soit pas contrôlé par un gestionnaire ASP.NET.
Développement de modules de code managé personnalisés
Le cycle de vie d'application ASP.NET peut être étendu avec des modules qui implémentent l'interface IHttpModule. Les modules qui implémentent l'interface IHttpModule sont des modules de code managé. Le pipeline intégré d'ASP.NET et IIS 7.0 est également extensible par le biais de modules de code natif, qui ne sont pas décrits dans cette rubrique. Pour plus d'informations sur les modules de code natif et sur la configuration des modules en général, consultez IIS Module Overview.
Vous pouvez définir un module de code managé comme un fichier de classe dans le dossier App_Code de l'application. Vous pouvez également créer le module comme un projet de bibliothèque de classes, le compiler et l'ajouter au dossier Bin de l'application. Après avoir créé le module personnalisé, vous devez l'inscrire avec IIS 7.0. Vous pouvez utiliser l'une des méthodes décrites pour la gestion des modules de code managé IIS 7.0. Par exemple, vous pouvez modifier le fichier Web.config d'une application pour inscrire le module de code managé uniquement pour cette application. Pour obtenir un exemple d'inscription de module, consultez Procédure pas à pas : création et inscription d'un module HTTP personnalisé.
Si un module est défini dans le dossier App_Code ou Bin d'une application et qu'il soit inscrit dans le fichier Web.config de l'application, le module est appelé uniquement pour cette application. Pour inscrire le module dans le fichier Web.config de l'application, vous utilisez l'élément modules contenu dans la section system.webServer. Pour plus d'informations, consultez Comment : configurer la section <system.webServer> pour IIS 7.0. Les modifications effectuées à l'aide du Gestionnaire des services IIS ou de l'outil Appcmd.exe sont reflétées dans le fichier Web.config de l'application.
Les modules de code managé peuvent également être inscrits dans l'élément modules du magasin de configuration d'IIS 7.0 (le fichier ApplicationHost.config). Les modules inscrits dans le fichier ApplicationHost.config ont une portée globale, car ils sont inscrits pour toutes les applications Web hébergées par IIS 7.0. De la même manière, les modules de code natif qui sont définis dans l'élément globalModules du fichier ApplicationHost.config ont une portée globale. Si un module global n'est pas exigé pour une application Web, vous pouvez le désactiver.
Exemple
L'exemple suivant représente un module personnalisé qui gère les événements LogRequest et PostLogRequest. Les gestionnaires d'événements sont inscrits dans la méthode Init du module.
Imports System
Imports System.Data
Imports System.Web
Imports System.Web.Security
Imports System.Web.UI
Imports Microsoft.VisualBasic
' Module that demonstrates one event handler for several events.
Namespace Samples
Public Class ModuleExample
Implements IHttpModule
Public Sub New()
' Constructor
End Sub
Public Sub Init(ByVal app As HttpApplication) Implements IHttpModule.Init
AddHandler app.LogRequest, AddressOf Me.App_Handler
AddHandler app.PostLogRequest, AddressOf Me.App_Handler
End Sub
Public Sub Dispose() Implements IHttpModule.Dispose
End Sub
' One for both the LogRequest and PostLogRequest events.
Public Sub App_Handler(ByVal source As Object, ByVal e As EventArgs)
Dim app As HttpApplication = CType(source, HttpApplication)
Dim context As HttpContext = app.Context
If (context.CurrentNotification = RequestNotification.LogRequest) Then
If Not (context.IsPostNotification) Then
' Put code here that is invoked when the LogRequest event is raised.
Else
' PostLogRequest
' Put code here that runs after the LogRequest event completes.
End If
End If
End Sub
End Class
End Namespace
using System;
using System.Data;
using System.Web;
using System.Web.Security;
using System.Web.UI;
// Module that demonstrates one event handler for several events.
namespace Samples
{
public class ModuleExample : IHttpModule
{
public ModuleExample()
{
// Constructor
}
public void Init(HttpApplication app)
{
app.LogRequest += new EventHandler(App_Handler);
app.PostLogRequest += new EventHandler(App_Handler);
}
public void Dispose()
{
}
// One handler for both the LogRequest and the PostLogRequest events.
public void App_Handler(object source, EventArgs e)
{
HttpApplication app = (HttpApplication)source;
HttpContext context = app.Context;
if (context.CurrentNotification == RequestNotification.LogRequest)
{
if (!context.IsPostNotification)
{
// Put code here that is invoked when the LogRequest event is raised.
}
else
{
// PostLogRequest
// Put code here that runs after the LogRequest event completes.
}
}
}
}
}
L'exemple suivant indique comment inscrire le module dans le fichier Web.config de l'application. Ajoutez la section de configuration system.webServer à l'intérieur de la section de configuration.
<system.webServer>
<modules>
<add name="ModuleExample" type="Samples.ModuleExample"/>
</modules>
</system.webServer>
Pour obtenir un exemple supplémentaire illustrant la création et l'inscription d'un module personnalisé, consultez Procédure pas à pas : création et inscription d'un module HTTP personnalisé.
Voir aussi
Concepts
Vue d'ensemble du cycle de vie des pages ASP.NET
Vue d'ensemble de la compilation ASP.NET