Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 5.0 und 6.0

Artikel
10/22/2014

Aktualisiert: November 2007

Dieses Thema bietet eine Übersicht über den Lebenszyklus von ASP.NET-Anwendungen. Wichtige Lebenszyklusereignisse werden aufgelistet, und es wird beschrieben, wie von Ihnen erstellter Code in den Lebenszyklus der Anwendung integriert werden kann. Die Informationen in diesem Thema gelten für IIS 5.0 und IIS 6.0. Informationen über den Lebenszyklus von ASP.NET-Anwendungen in IIS 7.0 finden Sie unter Übersicht über den Lebenszyklus von ASP.NET-Anwendungen für IIS 7.0.

Innerhalb von ASP.NET müssen mehrere Verarbeitungsschritte auftreten, damit eine ASP.NET-Anwendung initialisiert wird und Anforderungen verarbeitet werden. Zudem ist ASP.NET nur ein Teil der Webserverarchitektur, die die Anforderungen von Browsern bedient. Es ist wichtig, dass Sie den Lebenszyklus der Anwendung verstehen, damit Sie Code für die richtige Lebenszyklusphase schreiben können und so die beabsichtigte Wirkung erzielen.

Der Lebenszyklus von Anwendungen im Allgemeinen

In der folgenden Tabelle werden die Phasen des ASP.NET-Anwendungslebenszyklus beschrieben.

Phase	Beschreibung
Der Benutzer fordert eine Anwendungsressource vom Webserver an.	Der Lebenszyklus einer ASP.NET-Anwendung beginnt damit, dass der Browser eine Anforderung an den Webserver sendet (bei ASP.NET-Anwendungen ist das in der Regel IIS). ASP.NET ist eine ISAPI-Erweiterung unter dem Webserver. Wenn ein Webserver eine Anforderung erhält, überprüft er die Dateinamenerweiterung der angeforderten Datei. Er bestimmt, welche ISAPI-Erweiterung die Anforderung behandeln soll, und gibt die Anforderung an die entsprechende ISAPI-Erweiterung weiter. ASP.NET behandelt nur Dateinamenerweiterungen, die ASP.NET zugeordnet wurden, z. B. .aspx, .ascx, .ashx und .asmx. Hinweis: Wenn eine Dateinamenerweiterung ASP.NET nicht zugeordnet wurde, erhält ASP.NET die Anforderung nicht. Es ist wichtig, dies für Anwendungen mit ASP.NET-Authentifizierung zu wissen. Da HTM-Dateien z. B. in der Regel nicht ASP.NET zugeordnet sind, wird ASP.NET nicht die Authentifizierung oder Autorisierung von Anforderungen für HTM-Dateien überprüfen. Wenn Sie möchten, dass ASP.NET die Authentifizierung überprüft, selbst wenn eine Datei nur statischen Inhalt hat, sollten Sie die Datei mit einer Dateinamenerweiterung erstellen, die ASP.NET zugeordnet ist, z. B. .aspx. Hinweis: Wenn Sie einen benutzerdefinierten Handler für die Behandlung einer bestimmten Dateinamenerweiterung erstellen, müssen Sie ASP.NET die Erweiterung in IIS zuordnen und den Handler auch in der Datei Web.config der Anwendung registrieren. Weitere Informationen hierzu finden Sie unter Übersicht über HTTP-Handler und HTTP-Module.
ASP.NET erhält die erste Anforderung für die Anwendung.	Wenn ASP.NET die erste Anforderung für eine beliebige Ressource in einer Anwendung erhält, erstellt eine Klasse mit dem Namen ApplicationManager eine Anwendungsdomäne. Anwendungsdomänen ermöglichen das Isolieren von Anwendungen für globale Variablen und die getrennte Entladung jeder Anwendung. In einer Anwendungsdomäne wird eine Instanz der Klasse mit dem Namen HostingEnvironment erstellt, die Zugang zu Informationen über die Anwendung bietet, z. B. den Namen des Ordners, in dem die Anwendung gespeichert ist. Die folgende Darstellung veranschaulicht diese Beziehung: ASP.NET kompiliert nach Bedarf auch die Elemente auf der obersten Ebene der Anwendung, einschließlich des Anwendungscodes im Ordner App_Code. Weitere Informationen finden Sie weiter unten in diesem Thema unter "Kompilierungslebenszyklus".
Für jede Anforderung werden ASP.NET-Kernobjekte erstellt.	Nachdem die Anwendungsdomäne erstellt und das HostingEnvironment-Objekt instanziiert wurde, erstellt und instanziiert ASP.NET Kernobjekte, z. B.HttpContext, HttpRequest und HttpResponse. 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, einschließlich Cookies und Browserinformationen. Das HttpResponse-Objekt enthält die Antwort, die an den Client gesendet wird, einschließlich der gerenderten Ausgabe und der Cookies.
Der Anforderung wird ein HttpApplication-Objekt zugewiesen.	Nachdem alle Kernanwendungsobjekte initialisiert wurden, wird die Anwendung gestartet, indem eine Instanz der HttpApplication-Klasse erstellt wird. Verfügt die Anwendung über die Datei Global.asax, erstellt ASP.NET stattdessen eine Instanz der Global.asax-Klasse, die von der HttpApplication-Klasse abgeleitet ist, und verwendet die abgeleitete Klasse zur Darstellung der Anwendung. Hinweis: Wenn eine ASP.NET-Seite oder ein ASP.NET-Prozess zum ersten Mal in einer Anwendung angefordert wird, wird eine neue Instanz von HttpApplication erstellt. Um jedoch die Leistung zu steigern, können die HttpApplication-Instanzen für mehrere Anforderungen wiederverwendet werden. Wenn eine Instanz von HttpApplication erstellt wird, werden auch alle konfigurierten Module erstellt. Wenn beispielsweise die Anwendung entsprechend konfiguriert wurde, erstellt ASP.NET ein SessionStateModule-Modul. Nachdem alle konfigurierten Module erstellt wurden, wird die Init-Methode der HttpApplication-Klasse aufgerufen. Die folgende Darstellung veranschaulicht diese Beziehung:
Die Anforderung wird von der HttpApplication-Pipeline verarbeitet.	Die folgenden Ereignisse werden von der HttpApplication-Klasse ausgeführt, während die Anforderung verarbeitet wird. Die Ereignisse sind von besonderem Interesse für Entwickler, die die HttpApplication-Klasse erweitern möchten. Überprüfen Sie die Anforderung, die die vom Browser gesendeten Informationen untersucht und feststellt, ob potenziell schädliches Markup enthalten ist. Weitere Informationen finden Sie unter ValidateRequest und Übersicht über Skriptangriffe. Führen Sie eine URL-Zuordnung durch, wenn URLs im UrlMappingsSection-Abschnitt der Datei Web.config konfiguriert worden sind. Lösen Sie das BeginRequest-Ereignis aus. Lösen Sie das AuthenticateRequest-Ereignis aus. Lösen Sie das PostAuthenticateRequest-Ereignis aus. Lösen Sie das AuthorizeRequest-Ereignis aus. Lösen Sie das PostAuthorizeRequest-Ereignis aus. Lösen Sie das ResolveRequestCache-Ereignis aus. Lösen Sie das PostResolveRequestCache-Ereignis aus. Wählen Sie anhand der Dateinamenerweiterung der angeforderten Ressource (in der Konfigurationsdatei der Anwendung zugeordnet) eine Klasse, die zum Verarbeiten der Anforderung IHttpHandler implementiert. Falls die Anforderung ein Objekt (eine Seite) betrifft, das von der Page-Klasse abgeleitet ist, und die Seite kompiliert werden muss, kompiliert ASP.NET die Seite zuerst und erstellt anschließend eine Instanz davon. Lösen Sie das PostMapRequestHandler-Ereignis aus. Lösen Sie das AcquireRequestState-Ereignis aus. Lösen Sie das PostAcquireRequestState-Ereignis aus. Lösen Sie das PreRequestHandlerExecute-Ereignis aus. Rufen Sie die ProcessRequest-Methode (oder die asynchrone Version IHttpAsyncHandler.BeginProcessRequest) der entsprechenden IHttpHandler-Klasse für die Anforderung auf. Wenn die Anforderung z. B. eine Seite betrifft, behandelt die Instanz der aktuellen Seite diese Anforderung. Lösen Sie das PostRequestHandlerExecute-Ereignis aus. Lösen Sie das ReleaseRequestState-Ereignis aus. Lösen Sie das PostReleaseRequestState-Ereignis aus. Führen Sie die Antwortfilterung aus, wenn die Filter-Eigenschaft definiert ist. Lösen Sie das UpdateRequestCache-Ereignis aus. Lösen Sie das PostUpdateRequestCache-Ereignis aus. Lösen Sie das EndRequest-Ereignis aus. Lösen Sie das PreSendRequestHeaders-Ereignis aus. Lösen Sie das PreSendRequestContent-Ereignis aus.

Lebenszyklusereignisse und die Datei Global.asax

Die Anwendung löst während ihres Lebenszyklus Ereignisse aus, die Sie behandeln können, und ruft bestimmte Methoden auf, die Sie überschreiben können. Um Anwendungsereignisse oder Methoden zu behandeln, können Sie eine Datei mit dem Namen Global.asax im Stammverzeichnis der Anwendung erstellen.

Wenn Sie die Datei Global.asax erstellen, kompiliert ASP.NET sie in eine Klasse, die von der HttpApplication-Klasse abgeleitet ist, und verwendet diese abgeleitete Klasse zur Darstellung der Anwendung.

Eine Instanz von HttpApplication verarbeitet jeweils nur eine Anforderung. Das vereinfacht die Behandlung von Anwendungsereignissen, weil Sie nicht statische Member in der Anwendungsklasse nicht sperren müssen, wenn Sie auf sie zugreifen. Dadurch können Sie auch anforderungsspezifische Daten in nicht statischen Membern der Anwendungsklasse speichern. Zum Beispiel können Sie eine Eigenschaft in der Datei Global.asax definieren und ihr einen anforderungsspezifischen Wert zuweisen.

ASP.NET bindet Anwendungsereignisse durch die Verwendung der Benennungskonvention Application_event automatisch an Handler in der Datei Global.asax (Beispiel: Application_BeginRequest). Dies ähnelt dem Binden von ASP.NET-Seitenmethoden, wo die ASP.NET-Seitenmethoden automatisch an Ereignisse gebunden werden, z. B. an das Page_Load-Ereignis der Seite. Ausführliche Informationen finden Sie unter Übersicht über den Lebenszyklus von ASP.NET-Seiten.

Die Application_Start-Methode und die Application_End-Methode sind besondere Methoden, die HttpApplication-Ereignisse nicht darstellen. ASP.NET ruft sie einmal für die Lebensdauer der Anwendungsdomäne auf und nicht für jede HttpApplication-Instanz.

In der folgenden Tabelle werden einige der Ereignisse und Methoden aufgelistet, die während des Lebenszyklus der Anwendung verwendet werden. Es gibt viel mehr Ereignisse als hier aufgelistet sind, aber sie werden im Allgemeinen nicht verwendet.

Ereignis oder Methode	Beschreibung
Application_Start	Wird aufgerufen, wenn in einer ASP.NET-Anwendung die erste Ressource (z. B. eine Seite) angefordert wird. Die Application_Start-Methode wird nur einmal während des Lebenszyklus einer Anwendung aufgerufen. Sie können diese Methode verwenden, um Startaufgaben auszuführen, z. B. um Daten in den Cache zu laden und statische Werte zu initialisieren. Sie sollten während des Starts der Anwendung nur statische Daten festlegen. Legen Sie keine Instanzdaten fest, da diese nur der als Erstes erstellten Instanz der HttpApplication-Klasse zur Verfügung stehen.
Application_event	Zum entsprechenden Zeitpunkt im Lebenszyklus der Anwendung ausgelöst, wie weiter oben in diesem Thema in der Tabelle zum Lebenszyklus der Anwendung beschrieben. Application_Error kann in jeder Phase des Lebenszyklus der Anwendung ausgelöst werden. Application_EndRequest ist das einzige Ereignis, das garantiert in jeder Anforderung ausgelöst wird, da damit eine Anforderung kurzgeschlossen werden kann. Wenn z. B. zwei Module das Application_BeginRequest-Ereignis behandeln und das erste Modul eine Ausnahme auslöst, wird das Application_BeginRequest-Ereignis für das zweite Modul nicht aufgerufen. Die Application_EndRequest-Methode wird jedoch immer aufgerufen, um der Anwendung die Bereinigung der Ressourcen zu ermöglichen.
Init	Wird einmal für jede Instanz der HttpApplication-Klasse aufgerufen, nachdem alle Module erstellt worden sind.
Dispose	Aufgerufen, bevor die Anwendungsinstanz zerstört wird. Sie können diese Methode verwenden, um nicht verwaltete Ressourcen manuell freizugeben. Weitere Informationen finden Sie unter Bereinigen von nicht verwalteten Ressourcen.
Application_End	Einmal während der Lebensdauer der Anwendung aufgerufen, bevor die Anwendung entladen wird.

Kompilierungslebenszyklus

Bei der ersten Anforderung an eine Anwendung kompiliert ASP.NET Anwendungselemente in einer bestimmten Reihenfolge. Die ersten zu kompilierenden Elemente werden als Elemente der obersten Ebene bezeichnet. Nach der ersten Anforderung werden die Elemente der obersten Ebene nur neu kompiliert, wenn sich eine Abhängigkeit geändert hat. In der folgenden Tabelle wird die Reihenfolge beschrieben, in der Elemente der obersten Ebene von ASP.NET kompiliert werden.

Element	Beschreibung
App_GlobalResources	Die globalen Ressourcen der Anwendung werden kompiliert, und eine Ressourcenassembly wird erstellt. Alle Assemblys im Ordner Bin der Anwendung werden mit der Ressourcenassembly verknüpft.
App_WebResources	Proxytypen für Webdienste werden erstellt und kompiliert. Die resultierende Webverweisassembly wird ggf. mit der Ressourcenassembly verknüpft.
In der Datei Web.config definierte Profileigenschaften	Wenn in der Datei Web.config der Anwendung Profileigenschaften definiert sind, wird eine Assembly generiert, die ein Profilobjekt enthält.
App_Code	Quellcodedateien werden erzeugt, und eine oder mehrere Assemblys werden erstellt. Alle Codeassemblys und die Profilassembly werden ggf. mit der Ressourcenassembly und der Webverweisassembly verknüpft.
Global.asax	Das Anwendungsobjekt wird kompiliert und mit allen zuvor generierten Assemblys verknüpft.

Nachdem die Elemente der obersten Ebene der Anwendung kompiliert wurden, kompiliert ASP.NET Ordner, Seiten und ggf. weitere Elemente. In der folgenden Tabelle wird die Reihenfolge beschrieben, in der ASP.NET-Ordner und -Elemente kompiliert werden.

Element	Beschreibung
App_LocalResources	Wenn der Ordner mit dem angeforderten Element den Ordner App_LocalResources enthält, wird der Inhalt dieses Ordners für lokale Ressourcen kompiliert und mit der Assembly für globale Ressourcen verknüpft.
Einzelne Webseiten (ASPX-Dateien), Benutzersteuerelemente (ASCX-Dateien), HTTP-Handler (ASHX-Dateien) und HTTP-Module (ASMX-Dateien)	Werden nach Bedarf kompiliert und mit der Assembly für lokale Ressourcen sowie den Assemblys der obersten Ebene verknüpft.
Designs, Masterseiten, andere Quelldateien	SKIN-Dateien für einzelne Designs, Masterseiten und andere Quellcodedateien, auf die von Seiten verwiesen wird, werden kompiliert, wenn die Seite, die den Verweis enthält, kompiliert wird.

Kompilierte Assemblys werden auf dem Server zwischengespeichert, bei nachfolgenden Anforderungen wiederverwendet und nach Anwendungsneustarts beibehalten, solange der Quellcode nicht geändert wird.

Weil die Anwendung bei der ersten Anforderung kompiliert wird, kann die erste Anforderung einer Anwendung wesentlich mehr Zeit als die folgenden Anforderungen benötigen. Sie können die Anwendung vorkompilieren, um die für die erste Anforderung erforderliche Zeit zu verringern. Weitere Informationen hierzu finden Sie unter Gewusst wie: Vorkompilieren von ASP.NET-Websites.

Anwendungsneustarts

Das Ändern des Quellcodes der Webanwendung bewirkt, dass ASP.NET Quelldateien neu zu Assemblys kompiliert. Wenn Sie die Elemente der obersten Ebene in der Anwendung ändern, werden die anderen Assemblys in der Anwendung, die auf die Assemblys der obersten Ebene verweisen, ebenfalls neu kompiliert.

Zudem wird durch das Ändern, Hinzufügen oder Löschen bestimmter Typen von Dateien in bestimmten Ordnern der Anwendung ein Neustart der Anwendung verursacht. Die folgenden Aktionen verursachen einen Anwendungsneustart:

Das Hinzufügen, Ändern oder Löschen von Assemblys im Ordner Bin der Anwendung.
Das Hinzufügen, Ändern oder Löschen von Lokalisierungsressourcen in den Ordnern App_GlobalResources oder App_LocalResources.
Das Hinzufügen, Ändern oder Löschen der Datei Global.asax der Anwendung.
Das Hinzufügen, Ändern oder Löschen von Quellcodedateien im Verzeichnis App_Code.
Das Hinzufügen, Ändern oder Löschen der Profilkonfiguration.
Das Hinzufügen, Ändern oder Löschen von Webdienstverweisen im Verzeichnis App_WebReferences.
Das Hinzufügen, Ändern oder Löschen der Datei Web.config der Anwendung.

Wenn ein Neustart der Anwendung erforderlich ist, verarbeitet ASP.NET alle ausstehenden Anforderungen aus der vorhandenen Anwendungsdomäne und den alten Assemblys, bevor die Anwendungsdomäne neu gestartet wird und die neuen Assemblys geladen werden.

HTTP-Module

Der Lebenszyklus von ASP.NET-Anwendungen ist durch IHttpModule-Klassen erweiterbar. ASP.NET beinhaltet mehrere Klassen, die IHttpModule implementieren, z. B. die SessionStateModule-Klasse. Sie können auch eigene Klassen erstellen, die IHttpModule implementieren.

Wenn Sie der Anwendung Module hinzufügen, können die Module selbst Ereignisse auslösen. Die Anwendung kann diese Ereignisse in die Datei Global.asax abonnieren, indem die Konvention modulename_eventname verwendet wird. Um zum Beispiel das von einem FormsAuthenticationModule-Objekt ausgelöste Authenticate-Ereignis zu behandeln, können Sie einen Handler mit dem Namen FormsAuthentication_Authenticate erstellen.

Die SessionStateModule-Klasse wird standardmäßig in ASP.NET aktiviert. Alle Sitzungsereignisse werden automatisch als Session_event eingerichtet, z. B. Session_Start. Das Start-Ereignis wird jedes Mal ausgelöst, wenn eine neue Sitzung erstellt wird. Weitere Informationen finden Sie unter Übersicht über den ASP.NET-Sitzungszustand.