Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 7.0
Aktualisiert: November 2007
In diesem Thema wird der Lebenszyklus von ASP.NET-Anwendungen beschrieben, die im integrierten Modus von IIS 7.0 sowie mit .NET Framework 3.0 oder einer späteren Version ausgeführt werden. IIS 7.0 unterstützt auch den klassischen Modus, bei dem ASP.NET wie unter IIS 6.0 ausgeführt wird. Weitere Informationen hierzu finden Sie unter Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 5.0 und 6.0.
Die integrierte Pipeline von IIS 7.0 ist eine vereinheitlichte Pipeline für die Anforderungsverarbeitung, die Module mit systemeigenem und mit verwaltetem Code unterstützt. Module mit verwaltetem Code, die die IHttpModule-Schnittstelle implementieren, haben Zugriff auf alle Ereignisse in der Anforderungspipeline. Beispielsweise kann ein Modul mit verwaltetem Code zur ASP.NET-Formularauthentifizierung für ASP.NET-Webseiten (ASPX-Dateien) und für HTML-Seiten (HTM- oder HTML-Dateien) verwendet werden. Dies trifft zu, obwohl HTML-Seiten von IIS und ASP.NET als statische Ressourcen behandelt werden. Weitere Informationen zum integrierten Modus von IIS 7.0 finden Sie unter ASP.NET Integration with IIS7.
Dieses Thema enthält folgende Abschnitte:
Übersicht über die Architektur
Lebenszyklusphasen
Verwenden der Datei Global.asax
Module mit verwaltetem Code in IIS 7.0
Übersicht über die Architektur
Eine Anforderung im integrierten Modus von IIS 7.0 durchläuft Phasen, die auch Anforderungen für ASP.NET-Ressourcen in IIS 6.0 durchlaufen. In IIS 7.0 umfassen diese Phasen jedoch mehrere zusätzliche Anwendungsereignisse wie die Ereignisse MapRequestHandler, LogRequest und PostLogRequest.
Der Hauptunterschied zwischen den Verarbeitungsphasen in IIS 7.0 und IIS 6.0 liegt in der Art, wie ASP.NET in den IIS-Server integriert ist. In IIS 6.0 gibt es zwei Pipelines für die Anforderungsverarbeitung. Eine Pipeline dient für ISAPI-Filter und Erweiterungskomponenten mit systemeigenem Code. Die andere Pipeline dient für Anwendungskomponenten mit verwaltetem Code, wie z. B. ASP.NET. In IIS 7.0 ist die ASP.NET-Laufzeit in den Webserver integriert, sodass es für alle Anforderungen eine vereinheitlichte Pipeline für die Anforderungsverarbeitung gibt. ASP.NET-Entwickler haben durch die integrierte Pipeline folgende Vorteile:
Die integrierte Pipeline löst alle vom HttpApplication-Objekt bereitgestellten Ereignisse aus, wodurch vorhandene ASP.NET-HTTP-Module im integrierten Modus von IIS 7.0 ausgeführt werden können.
Sowohl Module mit systemeigenem als auch mit verwaltetem Code können auf Ebene des Webservers, der Website oder der Webanwendung konfiguriert werden. Dazu zählen auch die integrierten ASP.NET-Module mit verwaltetem Code für Sitzungszustand, Formularauthentifizierung, Profile und Rollenverwaltung. Darüber hinaus können Module mit verwaltetem Code für alle Anforderungen aktiviert oder deaktiviert werden, unabhängig davon, ob die Anforderung für eine ASP.NET-Ressource wie eine ASPX-Datei bestimmt ist.
Module mit verwaltetem Code können während jeder Phase in der Pipeline aufgerufen werden. Dies gilt auch für die Phase, bevor die Serververarbeitung für die Anforderung begonnen hat, nachdem die Serververarbeitung abgeschlossen ist und für die gesamte Zeitspanne dazwischen.
In der Datei Web.config einer Anwendung können Sie Module registrieren und aktivieren bzw. deaktivieren.
In der folgenden Abbildung wird die Konfiguration der Anforderungspipeline einer Anwendung gezeigt. Das Beispiel umfasst Folgendes:
Das Anonymous-Modul mit systemeigenem Code und das Forms-Modul mit verwaltetem Code (entspricht FormsAuthenticationModule). Diese Module werden konfiguriert und während der Authentication-Phase der Anforderung aufgerufen.
Das Basic-Modul mit systemeigenem Code und das Windows-Modul mit verwaltetem Code (entspricht WindowsAuthenticationModule). Diese werden dargestellt, jedoch nicht für die Anwendung konfiguriert.
Die Execute handler-Phase, in der der Handler (ein Modul, dessen Gültigkeitsbereich eine URL ist) aufgerufen wird, um die Antwort zu generieren. Bei ASPX-Dateien wird der PageHandlerFactory-Handler verwendet, um auf die Anforderung zu reagieren. Bei statischen Dateien antwortet das StaticFileModule-Modul mit systemeigenem Code auf die Anforderung.
Das Trace-Modul mit systemeigenem Code. Dieses wird dargestellt, jedoch nicht für die Anwendung konfiguriert.
Die Custom module-Klasse mit verwaltetem Code. Diese wird während der Log request-Phase aufgerufen.
.png)
Informationen zu bekannten Kompatibilitätsproblemen mit ASP.NET-Anwendungen, die aus früheren Versionen von IIS zu IIS 7.0 migriert werden, finden Sie im Abschnitt „Known Differences Between Integrated Mode and Classic Mode“ von Upgrading ASP.NET Applications to IIS 7.0: Differences between IIS 7.0 Integrated Mode and Classic mode.
Lebenszyklusphasen
In der folgenden Tabelle sind die Phasen des Lebenszyklus von ASP.NET-Anwendungen im integrierten Modus von IIS 7.0 aufgelistet.
Phase |
Beschreibung |
|---|---|
Für eine Anwendungsressource wird eine Anforderung durchgeführt. |
Der Lebenszyklus einer ASP.NET-Anwendung beginnt mit einer Anforderung, die von einem Browser an einen Webserver gesendet wird. Im klassischen Modus von IIS 7.0 sowie in IIS 6.0 ist die ASP.NET-Anforderungspipeline von der Webserverpipeline getrennt. Module werden nur auf Anforderungen angewendet, die zur ASP.NET-ISAPI-Erweiterung weitergeleitet werden. Wenn die Dateinamenerweiterung des angeforderten Ressourcentyps nicht explizit ASP.NET zugeordnet ist, wird die ASP.NET-Funktionalität für die Anforderung nicht aufgerufen, da sie nicht von der ASP.NET-Laufzeit verarbeitet wird. Im integrierten Modus von IIS 7.0 werden alle Anforderungen von einer einheitlichen Pipeline behandelt. Wenn die integrierte Pipeline eine Anforderung empfängt, durchläuft die Anforderung die üblichen Phasen. Diese Phasen werden durch die RequestNotification-Enumeration dargestellt. Alle Anforderungen können für die Verwendung der ASP.NET-Funktionalität konfiguriert werden, da diese Funktionalität in Modulen mit verwaltetem Code gekapselt ist, die Zugang zur Anforderungspipeline haben. Obwohl die Dateinamenerweiterung .htm beispielsweise ASP.NET nicht explizit zugeordnet ist, werden bei einer Anforderung für eine HTML-Seite weiterhin ASP.NET-Module aufgerufen. Dadurch können Sie die ASP.NET-Authentifizierung und -Autorisierung für alle Ressourcen nutzen. |
Die einheitliche Pipeline empfängt die erste Anforderung für die Anwendung. |
Wenn die einheitliche Pipeline die erste Anforderung für eine Ressource in einer Anwendung empfängt, wird eine Instanz der ApplicationManager-Klasse erstellt, bei der es sich um die Anwendungsdomäne handelt, in der die Anforderung verarbeitet wird. Anwendungsdomänen stellen die Isolation zwischen Anwendungen für globale Variablen bereit und ermöglichen das separate Entladen der einzelnen Anwendungen. In einer Anwendungsdomäne wird eine Instanz der HostingEnvironment-Klasse erstellt, die Zugang zu Informationen über die Anwendung bietet, z. B. den Namen des Ordners, in dem die Anwendung gespeichert ist. Während der ersten Anforderung werden Elemente der obersten Ebene ggf. kompiliert, u. a. auch der Anwendungscode im Ordner App_Code. Der Ordner App_Code kann benutzerdefinierte Module und Handler enthalten, wie unter Module mit verwaltetem Code in IIS 7.0 weiter unten in diesem Thema beschrieben wird. |
Für jede Anforderung werden Antwortobjekte erstellt. |
Nachdem die Anwendungsdomäne erstellt und das HostingEnvironment-Objekt instanziiert wurde, werden Anwendungsobjekte wie HttpContext, HttpRequest und HttpResponse erstellt und instanziiert. Die HttpContext-Klasse enthält Objekte, die für die aktuelle Anwendungsanforderung spezifisch sind, z. B. das HttpRequest-Objekt und das HttpResponse-Objekt. Das HttpRequest-Objekt enthält Informationen über die aktuelle Anforderung, z. B. über Cookies und den Browser. Das HttpResponse-Objekt enthält die Antwort, die an den Client gesendet wird, einschließlich gerenderter Ausgabe und Cookies. Zwischen IIS 6.0 und IIS 7.0, ausgeführt im integrierten Modus und mit .NET Framework 3.0 oder späteren Versionen, gibt es folgende grundlegende Unterschiede:
|
Der Anforderung wird ein HttpApplication-Objekt zugewiesen. |
Nachdem alle Anwendungsobjekte initialisiert wurden, wird die Anwendung gestartet, indem eine Instanz der HttpApplication-Klasse erstellt wird. Wenn die Anwendung über eine Global.asax-Datei verfügt, wird von ASP.NET stattdessen eine Instanz der Global.asax-Klasse erstellt, die von der HttpApplication-Klasse abgeleitet wird. Die abgeleitete Klasse wird dann für die Darstellung der Anwendung verwendet. .gif "Hinweis") Hinweis:
Wenn eine ASP.NET-Seite oder ein ASP.NET-Prozess zum ersten Mal in einer Anwendung angefordert wird, wird eine neue Instanz der HttpApplication-Klasse erstellt. Um jedoch die Leistung zu steigern, können die HttpApplication-Instanzen für mehrere Anforderungen wiederverwendet werden.
Welche ASP.NET-Module geladen werden (z. B. SessionStateModule), ist abhängig von den Modulen mit verwaltetem Code, die die Anwendung von einer übergeordneten Anwendung erbt. Außerdem ist entscheidend, welche Module im Konfigurationsabschnitt der Datei Web.config der Anwendung konfiguriert sind. Module werden im modules-Element im Abschnitt system.webServer der Datei Web.config für die Anwendung hinzugefügt oder entfernt. Weitere Informationen hierzu finden Sie unter Gewusst wie: Konfigurieren des <system.webServer>-Abschnitts für IIS 7.0. |
Die Anforderung wird von der HttpApplication-Pipeline verarbeitet. |
Während die Anforderung verarbeitet wird, werden von der HttpApplication-Klasse die folgenden Aufgaben ausgeführt. Die Ereignisse sind hilfreich für Seitenentwickler, die Code ausführen möchten, wenn wichtige Anforderungspipelineereignisse ausgelöst werden. Sie sind außerdem nützlich, wenn Sie ein benutzerdefiniertes Modul entwickeln, das für alle Anforderungen an die Pipeline aufgerufen werden soll. Benutzerdefinierte Module implementieren die IHttpModule-Schnittstelle. Im integrierten Modus von IIS 7.0 müssen Ereignishandler in der Init-Methode eines Moduls registriert werden.
|
Verwenden der Datei Global.asax
Der Datei Global.asax wird im integrierten Modus in IIS 7.0 ähnlich verwendet wie in ASP.NET in IIS 6.0. Weitere Informationen finden Sie im Abschnitt "Lebenszyklusereignisse und die Datei Global.asax" in Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 5.0 und 6.0.
Ein Unterschied ist, dass Sie Handler für die Ereignisse MapRequestHandler, LogRequest und PostLogRequest hinzufügen können. Diese Ereignisse werden für Anwendungen unterstützt, die im integrierten Modus von IIS 7.0 und mit .NET Framework 3.0 oder einer späteren Version ausgeführt werden.
Sie können Anwendungsereignishandler in der Datei Global.asax bereitstellen, um Code hinzuzufügen, der für alle von ASP.NET behandelten Anforderungen ausgeführt wird, wie z. B. Anforderungen für ASPX- und AXD-Seiten. Handlercode in der Datei Global.asax wird jedoch nicht bei Anforderungen von Nicht-ASP.NET-Ressourcen aufgerufen, wie z. B. statische Dateien. Um verwalteten Code für alle Ressourcen auszuführen, erstellen Sie ein benutzerdefiniertes Modul, das die IHttpModule-Schnittstelle implementiert. Das benutzerdefinierte Modul wird bei allen Anforderungen von Ressourcen in der Anwendung ausgeführt, auch wenn der Ressourcenhandler kein ASP.NET-Handler ist.
Module mit verwaltetem Code in IIS 7.0
Zu den ASP.NET-Modulen mit verwaltetem Code, die in IIS 7.0 konfiguriert und geladen werden können, zählen folgende:
Für die Konfiguration von IIS 7.0-Modulen mit verwaltetem Code können Sie eine der folgenden Methoden verwenden:
Verwenden Sie IIS-Manager. Weitere Informationen finden Sie unter Gewusst wie: Öffnen des IIS-Managers.
Verwenden Sie das IIS 7.0-Befehlszeilentool (Appcmd.exe). Weitere Informationen finden Sie unter IIS 7.0 Command-Line Tool.
Bearbeiten Sie den XML-basierten Konfigurationsspeicher von IIS 7.0. Weitere Informationen finden Sie unter IIS 7.0: IIS 7.0 Configuration Store.
Wenn ein ASP.NET-Modul mit verwaltetem Code, beispielsweise das FormsAuthenticationModule-Modul, für das Laden in IIS 7.0 konfiguriert ist, verfügt es über Zugriff auf alle Ereignisse in der Anforderungspipeline. Dies bedeutet, dass alle Anforderungen das Modul mit verwaltetem Code durchlaufen. Für die FormsAuthenticationModule-Klasse bedeutet dies, dass statische Inhalte mithilfe von Formularauthentifizierung geschützt werden können, auch wenn diese nicht von einem ASP.NET-Handler behandelt werden.
Entwickeln von benutzerdefinierten Modulen mit verwaltetem Code
Der ASP.NET-Anwendungslebenszyklus kann mit Modulen erweitert werden, die die IHttpModule-Schnittstelle implementieren. Module, die die IHttpModule-Schnittstelle implementieren, sind Module mit verwaltetem Code. Die integrierte Pipeline von ASP.NET und IIS 7.0 ist auch durch Module mit systemeigenem Code erweiterbar, die in diesem Thema nicht behandelt werden. Weitere Informationen zu Modulen mit systemeigenem Code und zur allgemeinen Konfiguration von Modulen finden Sie unter IIS Module Overview.
Sie können ein Modul mit verwaltetem Code als Klassendatei im Ordner App_Code der Anwendung definieren. Das Modul kann auch als Klassenbibliothekprojekt erstellt, kompiliert und dem Ordner Bin der Anwendung hinzugefügt werden. Nachdem das benutzerdefinierte Modul erstellt wurde, müssen Sie es in IIS 7.0 registrieren. Dazu können Sie eine der Methoden verwenden, die für die Verwaltung von IIS 7.0-Modulen mit verwaltetem Code beschrieben wurden. Beispielsweise können Sie die Datei Web.config einer Anwendung bearbeiten, um das Modul mit verwaltetem Code nur für diese Anwendung zu registrieren. Ein Beispiel für die Registrierung eines Moduls finden Sie unter Exemplarische Vorgehensweise: Erstellen und Registrieren eines benutzerdefinierten HTTP-Moduls.
Wenn ein Modul im Ordner App_Code oder Bin einer Anwendung definiert und in der Datei Web.config der Anwendung registriert ist, wird das Modul ausschließlich für diese Anwendung aufgerufen. Die Registrierung des Moduls in der Datei Web.config der Anwendung können Sie mithilfe des modules-Elements im Abschnitt system.webServer durchführen. Weitere Informationen hierzu finden Sie unter Gewusst wie: Konfigurieren des <system.webServer>-Abschnitts für IIS 7.0. Bei Änderungen, die mit IIS-Manager oder dem Tool Appcmd.exe vorgenommen wurden, wird auch die Datei Web.config der Anwendung geändert.
Module mit verwaltetem Code können auch im modules-Element des Konfigurationsspeichers von IIS 7.0 (die Datei ApplicationHost.config) registriert werden. In der Datei ApplicationHost.config registrierte Module haben einen globalen Gültigkeitsbereich, da sie für alle von IIS 7.0 gehosteten Webanwendungen registriert sind. Ähnlich haben Module mit systemeigenem Code, die im globalModules-Element der Datei ApplicationHost.config definiert werden, einen globalen Gültigkeitsbereich. Wenn ein globales Modul für eine Webanwendung nicht benötigt wird, können Sie es deaktivieren.
Beispiel
Im folgenden Beispiel wird ein benutzerdefiniertes Modul dargestellt, das das LogRequest-Ereignis und das PostLogRequest-Ereignis behandelt. Ereignishandler werden in der Init-Methode des Moduls registriert.
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.
}
}
}
}
}
Im folgenden Beispiel wird gezeigt, wie das Modul in der Datei Web.config der Anwendung registriert wird. Fügen Sie den Konfigurationsabschnitt system.webServer innerhalb des configuration-Abschnitts hinzu.
<system.webServer>
<modules>
<add name="ModuleExample" type="Samples.ModuleExample"/>
</modules>
</system.webServer>
Ein weiteres Beispiel für die Erstellung und Registrierung eines benutzerdefinierten Moduls finden Sie unter Exemplarische Vorgehensweise: Erstellen und Registrieren eines benutzerdefinierten HTTP-Moduls.
Siehe auch
Konzepte
Übersicht über den Lebenszyklus von ASP.NET-Seiten
Übersicht über die ASP.NET-Kompilierung