ASP.NET-Integration in IIS 7

von Mike Volodarsky

Einführung

ASP.NET ist seit Veröffentlichung der Plattform die erste Wahl für die Entwicklung von Webanwendungen auf der Windows- bzw. IIS-Plattform. ASP.NET 2.0 hat die Webanwendungsentwicklung weiter vorangebracht und ermöglicht es Entwicklern, in kürzerer Zeit noch leistungsfähigere Anwendungen zu erstellen.

Durch IIS 7 und höhere Versionen wird ASP.NET noch weiter verbessert, indem das ASP.NET-Laufzeiterweiterbarkeitsmodell in Core Server integriert wird. Dadurch können Entwickler IIS-Server vollständig mit den umfangreichen Möglichkeiten von ASP.NET 2.0 und .NET Framework erweitern, anstatt die weniger leistungsfähigen IIS-C++-APIs zu verwenden. Bereits vorhandene ASP.NET-Anwendungen profitieren durch die Verwendung vorhandener ASP.NET-Features wie Formularauthentifizierung, Rollen und Ausgabezwischenspeicherung aller Inhalte ebenfalls sofort von einer engeren Integration.

IIS bietet zwar standardmäßig die verbesserte ASP.NET-Integration, Sie haben jedoch die Wahl: IIS unterstützt sowohl die neuen als auch die alten ASP.NET-Integrationsmodi, die parallel auf dem gleichen Server verwendet werden können.

In diesem Artikel werden die Verbesserungen, die der ASP.NET-Integrationsmodus mit sich bringt, sowie die Architektur der beiden Modi und die Vorgehensweise zum Auswählen und Konfigurieren der Integrationsmodi für ASP.NET-Anwendungen erläutert.

ASP.NET-Verbesserungen in IIS 7 und höheren Versionen

Die bessere ASP.NET-Integration in IIS verbessert bereits vorhandene Anwendungen und ermöglicht neuen Anwendungen die Nutzung von ASP.NET-Features auf folgende Weise:

• ASP.NET-Dienste können für alle Inhaltstypen verwendet werden. In der Vergangenheit waren ASP.NET-Funktionen wie Formularauthentifizierung, Rollen, URL-Autorisierung und Ausgabezwischenspeicherung nur für ASP.NET-Inhaltstypen wie ASPX-Seiten verfügbar. Statische Dateien, ASP-Seiten und andere Inhaltstypen konnten von diesen Diensten nicht profitieren.

In IIS werden alle ASP.NET-Dienste einheitlich für alle Inhalte bereitgestellt. So können Sie z. B. alle Webinhalte (einschließlich Bildern und ASP-Seiten) mit Ihrer vorhandenen ASP.NET 2.0-Zugriffssteuerungslösung schützen, die auf ASP.NET-Formularauthentifizierung, Mitgliedschaft und Anmeldesteuerungen basiert.

• IIS kann vollständig mit ASP.NET erweitert werden. In früheren Versionen von IIS musste die Servererweiterbarkeit aufgrund der Laufzeiteinschränkungen von ASP.NET häufig mithilfe des nativen ISAPI-Filters oder mithilfe des Erweiterungserweiterungsmodus entwickelt werden.

Mit IIS können ASP.NET-Module direkt und mit der gleichen Laufzeittreue wie Module, die mit der nativen Server-API (C++) entwickelt wurden, in die Serverpipeline eingebunden werden. ASP.NET-Module können in allen Laufzeitphasen der Anforderungsverarbeitungspipeline und in beliebiger Reihenfolge in Bezug auf native Module ausgeführt werden. Die ASP.NET-API wird auch erweitert, um mehr Kontrolle über die Anforderungsverarbeitung zu bieten als bislang möglich war.

• Vereinheitlichte Serverruntime. Die engere ASP.NET-Integration vereinheitlicht auch viele der Features zwischen IIS und ASP.NET.

IIS bietet eine vereinheitlichte Konfiguration für Module und Handler von IIS und ASP.NET. Viele weitere Features wie etwa benutzerdefinierte Fehler und die Ablaufverfolgung wurden vereinheitlicht, um eine bessere Verwaltung und einen einheitlichen Anwendungsentwurf zu ermöglichen.

Architektur der ASP.NET-Integration

In IIS 6.0 und früheren Releases wurde ASP.NET als IIS-ISAPI-Erweiterung implementiert.

In diesen früheren Releases wurde eine an einen ASP.NET-Inhaltstyp gerichtete Anforderung von IIS verarbeitet und dann an die ISAPI-DLL von ASP.NET weitergeleitet, die als Host für die ASP.NET-Anforderungspipeline und das Seitenframework fungierte. Anforderungen für ASP.NET-fremde Inhalte wie etwa ASP-Seiten oder statische Dateien wurden von IIS oder anderen ISAPI-Erweiterungen verarbeitet und waren für ASP.NET nicht sichtbar.

Die größte Einschränkung dieses Modells bestand darin, dass Dienste, die von ASP.NET-Modulen und benutzerdefiniertem ASP.NET-Anwendungscode bereitgestellt wurden, für ASP.NET-fremde Anforderungen nicht verfügbar waren. Darüber hinaus hatten ASP.NET-Module keine Auswirkungen auf bestimmte Teile der IIS-Anforderungsverarbeitung, die vor und nach dem ASP.NET Ausführungspfad aufgetreten ist.

Abbildung 1: IIS 6.0- und ASP.NET-Pipelines

In IIS überlagert die ASP.NET-Anforderungsverarbeitungspipeline die IIS-Pipeline direkt und stellt im Grunde einen Wrapper dafür dar, anstatt in sie eingebunden zu werden.

IIS verarbeitet eingehende Anforderungen für beliebige Inhaltstypen – mit Anforderungsverarbeitung in allen Phasen durch native IIS-Module sowie durch ASP.NET-Module. Dadurch können Dienste, die von ASP.NET-Modulen bereitgestellt werden (wie etwa Formularauthentifizierung oder Ausgabecache) für Anforderungen an ASP-Seiten, PHP-Seiten, statische Dateien usw. verwendet werden.

Dank der Möglichkeit der direkten Einbindung in die Serverpipeline können ASP.NET-Module IIS-Funktionen ersetzen bzw. vor oder nach ihnen ausgeführt werden. Dies ermöglicht z. B. ein benutzerdefiniertes ASP.NET-Standardauthentifizierungsmodul, das den Mitgliedschaftsdienst und die SQL Server-Benutzerdatenbank verwendet, um das integrierte IIS-Standardauthentifizierungsfeature zu ersetzen, das nur mit Windows-Konten funktioniert.

Darüber hinaus nutzen die erweiterten ASP.NET-APIs die direkte Integration, um weitere Anforderungsverarbeitungsaufgaben zu ermöglichen. Beispielsweise können ASP.NET-Module Anforderungsheader ändern, bevor andere Komponenten die Anforderung verarbeiten, indem sie vor der Ausführung von ASP-Anwendungen einen Accept-Language-Header einfügen, wodurch lokalisierte Inhalte basierend auf der Benutzereinstellung an den Client zurückgesendet werden.

Abbildung 2: Integrierter Modus von IIS 7 und höheren Versionen

Aufgrund der Laufzeitintegration können IIS und ASP.NET die gleiche Konfiguration verwenden, um Servermodule zu aktivieren und zu sortieren sowie um Handlerzuordnungen zu konfigurieren. Zu weiteren vereinheitlichten Funktionen zählen unter anderem die Ablaufverfolgung, benutzerdefinierte Fehler und die Ausgabezwischenspeicherung.

Kompatibilität

Die Architektur behält vor allem die Laufzeitarchitektur und die APIs von ASP.NET bei, sodass bereits vorhandene ASP.NET-Anwendungen und -Dienste direkt nach der Installation funktionieren. Mit einigen wenigen Änderungen können die bereits vorhandenen ASP.NET-Anwendungen und -Dienste die neuen ASP.NET-Funktionen nutzen.

Ebenso können Entwickler weiterhin neue Anwendungen für die vertrauten ASP.NET-APIs schreiben und trotzdem von den Vorteilen der Laufzeitintegration profitieren.

Für ASP.NET-Anwendungen mit spezifischen Kompatibilitätsanforderungen, die vom integrierten Modus nicht erfüllt werden, stellt IIS weiterhin den klassischen ASP.NET-Modus. Administratoren können den gewünschten Integrationsmodus pro Anwendungspool auswählen, sodass Anwendungen, die sowohl den neuen als auch den klassischen ASP.NET-Modus verwenden, parallel auf dem gleichen Server verwendet werden können.

Migrieren von ASP.NET-Anwendungen zu IIS 7 und höheren Versionen (integrierter Modus)

In IIS ist ASP.NET standardmäßig für den Betrieb im neuen integrierten Modus konfiguriert. Dadurch kann Ihre Anwendung mit minimalen Änderungen von den Verbesserungen des integrierten Modus profitieren.

Aufgrund der Vereinheitlichung der Konfiguration müssen manche Anwendungen ggf. migriert werden, damit sie im integrierten Modus ordnungsgemäß funktionieren. Der Server unterstützt Sie standardmäßig bei der Migration. Er erkennt Anwendungen, die migriert werden müssen, und gibt eine Fehlermeldung zurück, die Sie dazu auffordert, die Anwendung zu migrieren.

Der Migrationsfehler wird durch folgende Konfigurationen verursacht:

1. In der Datei „Web.config“ der Anwendung wird die Konfiguration <httpModules> definiert.
   Die Anwendung lädt neue ASP.NET-Module oder entfernt vorhandene Module.
   Im integrierten Modus werden ASP.NET-Module mit nativen Modulen im vereinheitlichten Konfigurationsabschnitt <system.webServer>/<modules> angegeben.
   Die im Konfigurationsabschnitt <system.web>/<httpModules> angegebenen ASP.NET-Module müssen in den neuen Konfigurationsabschnitt verschoben werden, um wirksam zu werden. Neue ASP.NET-Module müssen daraufhin direkt dem vereinheitlichten Abschnitt <modules> hinzugefügt werden.
2. In der Datei „Web.config“ der Anwendung wird die Konfiguration <httpHandlers> definiert.
   Die Anwendung verwendet für einige Inhaltstypen benutzerdefinierte Handlerzuordnungen.
   Im integrierten Modus müssen ASP.NET-Handlerzuordnungen im vereinheitlichten Konfigurationsabschnitt <system.webServer>/<handlers> angegeben werden, damit sie wirksam werden. Neue ASP.NET-Handlerzuordnungen müssen daraufhin direkt dem vereinheitlichten Abschnitt <handlers> hinzugefügt werden.
   In diesem Abschnitt wird sowohl die ASP.NET-Konfiguration <httpHandlers> als auch die IIS-Skriptzuordnungskonfiguration ersetzt. Diese beiden Konfigurationen mussten bislang für die Einrichtung einer ASP.NET-Handlerzuordnung konfiguriert werden.
3. In der Datei „Web.config“ der Anwendung wird die Konfiguration <identity impersonate="true" /> definiert.
   Die Anwendung führt einen Identitätswechsel mit Clientanmeldeinformationen durch. Dies ist besonders bei Intranetanwendungen üblich. Im integrierten Modus ist die Annahme der Clientidentität in einigen frühen Anforderungsverarbeitungsphasen nicht verfügbar. In den meisten Fällen ist das kein Problem, und Sie können den Migrationsfehler deaktivieren. Andernfalls muss die Anwendung so konfiguriert werden, dass sie im klassischen ASP.NET-Modus ausgeführt wird.

Wenn der Migrationsfehler generiert wird, kann entweder die Anwendungskonfiguration migriert (in den ersten beiden Fällen empfohlen) oder die Anwendung so verschoben werden, dass sie den klassischen ASP.NET-Modus verwendet (im dritten Fall).

Migrieren der Anwendungskonfiguration

IIS migriert die Anwendung mithilfe des Befehlszeilentools „AppCmd.exe“. Die Migrationsfehlermeldung enthält den Befehl, der im Befehlszeilenfenster ausgeführt wird. Dieser muss mit Administratorrechten ausgeführt werden, um Ihre Anwendung sofort zum integrierten Modus zu migrieren.

Das grundlegende Format des Migrationsbefehls lautet wie folgt:

%windir%\system32\inetsrv\APPCMD.EXE migrate config <Application Path>

Dabei ist <Application Path> der virtuelle Pfad der Anwendung einschließlich des Sitenamens (z. B. „Standardwebsite/app1“).

Nach Abschluss der Migration wird Ihre Anwendung sowohl im integrierten als auch im klassischen Modus ohne Probleme ausgeführt.

Hinweis

Wenn Sie die Konfiguration nach der Migration ändern, werden Sie vom Server nicht erneut zur Migration aufgefordert. Nach der ersten Migration müssen Sie sicherstellen, dass Ihre Konfiguration zwischen den beiden Modi synchron bleibt. Sie können die Anwendung mithilfe des Befehlszeilentools „AppCmd.exe“ noch einmal manuell migrieren.

Zurückkehren zum klassischen ASP.NET-Integrationsmodus

Wenn Sie lieber zum klassischen ASP.NET-Modus zurückkehren möchten, verschieben Sie Ihre Anwendung in einen Anwendungspool, der für die Ausführung im klassischen Modus konfiguriert ist. Andere Anwendungen werden parallel zum klassischen Modus weiterhin im neuen integrierten Modus ausgeführt.

Weitere Informationen zum Verschieben einer Anwendung in den klassischen ASP.NET-Modus finden Sie unter „Ändern des ASP.NET-Modus für eine Anwendung“.

Deaktivieren der Migrationsfehlermeldung

Wenn Sie Ihre Konfiguration manuell migriert haben oder im integrierten Modus bleiben möchten, ohne Ihre Konfiguration zu migrieren (nicht empfohlen), können Sie die Migrationsfehlermeldung deaktivieren, indem Sie der Datei „Web.config“ der Anwendung Folgendes hinzufügen:

<system.webServer> 
    <validation validateIntegratedModeConfiguration="false" />    
</system.webServer>

Hinweis

Der Server deaktiviert die Fehlermeldung automatisch, nachdem die Migration mithilfe des Befehlszeilentools „AppCmd.exe“ migriert wurde.

Wenn Sie die Migrationsfehlermeldung manuell deaktivieren, müssen Sie sich vergewissern, dass Ihre Anwendung im integrierten Modus ordnungsgemäß funktioniert, da der Server keine Warnungen hinsichtlich der nicht unterstützten Konfiguration mehr bereitstellt.

Ändern des ASP.NET-Modus für eine Anwendung

Falls Ihre Anwendung im integrierten ASP.NET-Modus nicht ordnungsgemäß funktioniert, können Sie sie in den klassischen ASP.NET-Modus verschieben, indem Sie sie in einem anderen Anwendungspool platzieren. Jeder Anwendungspool ist individuell für die Verwendung des gewünschten ASP.NET-Integrationsmodus konfiguriert. Dadurch können Gruppen von Anwendungen, die unterschiedliche ASP.NET-Integrationsmodi verwenden, parallel auf dem gleichen Server ausgeführt werden.

So ändern Sie den ASP.NET-Integrationsmodus für eine Anwendung

1. Suchen Sie nach einem Anwendungspool, der für die Verwendung des gewünschten Modus konfiguriert ist, oder erstellen Sie einen solchen Anwendungspool.
   Standardmäßig werden alle neuen Anwendungspools im integrierten Modus ausgeführt.
   Das ASP.NET-Setup stellt einen Anwendungspool mit dem Namen Klassischer .NET AppPool bereit, der im klassischen ASP.NET-Integrationsmodus ausgeführt wird. Dieser Anwendungspool kann für Anwendungen verwendet werden, die nicht im integrierten Modus ausgeführt werden sollen.
   Sie können auch den ASP.NET-Modus des vorhandenen Anwendungspools ändern. Hierzu können Sie das IIS-Verwaltungstool oder das Befehlszeilentool „AppCmd.exe“ verwenden oder die Anwendungspoolkonfiguration manuell bearbeiten.
2. Konfigurieren Sie die Anwendung so, dass sie diesen Anwendungspool verwendet.
   Jede Anwendung ist für die Verwendung eines bestimmten Anwendungspools konfiguriert. Standardmäßig verwenden alle Anwendungen den im integrierten Modus ausgeführten Standardanwendungspool DefaultAppPool.
   Sie können den Anwendungspool einer Anwendung ändern. Hierzu können Sie das IIS-Verwaltungstool oder das Befehlszeilentool „AppCmd.exe“ verwenden oder die Anwendungskonfiguration manuell bearbeiten.

Auswählen einer ASP.NET-Version für eine Anwendung

In der Vergangenheit hat IIS parallel mehrere ASP.NET- bzw. CLR-Versionen unterstützt. Beispielsweise ermöglicht IIS das Ausführen von ASP.NET-Anwendungen mit .NET Framework 1.1 und 2.0 auf dem gleichen Server. Diese Unterstützung wurde durch die Zuordnung einer entsprechenden Version von „ASPNET_isapi.dll“ bereitgestellt, um Anforderungen für den ASP.NET-Inhalt mithilfe der IIS-Skriptzuordnungskonfiguration zu verarbeiten.

Sie können z. B. die folgende Skriptzuordnungskonfiguration verwenden, um die parallele Unterstützung zu aktivieren:

1. ASP.NET 1.1-Anwendung für „/app1“:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
2. ASP.NET 2.0-Anwendung für „/app2“:
   *.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

Wenn die Anwendung eine *.aspx-Anforderung empfängt, lädt IIS die angegebene Datei „aspnet_isapi.dll“, die die korrekte CLR-Version in den Arbeitsprozess lädt, und verarbeitet die Anforderung.

ASP.NET bietet außerdem folgende Möglichkeiten zum Konfigurieren paralleler Skriptzuordnungen:

1. MMC-Erweiterung von ASP.NET: Wenn Sie die zu verwendende Version von ASP.NET auswählen, konfiguriert die Erweiterung automatisch die Skriptzuordnungen für die Anwendung, um auf die korrekte Version von „aspnet_isapi.dll“ zu verweisen.
2. „aspnet_regiis.exe“ von ASP.NET: Verwenden Sie die Optionen „-i“ und „-r“, um die Skriptzuordnungen zu installieren, die auf die entsprechende ASP.NET-Version verweisen.

Da in einen Arbeitsprozess nur eine einzelne CLR-Version geladen werden kann, dürfen zwei Anwendungen, die unterschiedliche Versionen von ASP.NET verwenden, nie so konfiguriert sein, dass sie im gleichen Anwendungspool vorhanden sind. Dieser Fehler wird häufig gemacht und führt dazu, dass die erste Anforderung die CLR der entsprechenden Datei vom Typ „aspnet_isapi.dll“ lädt und nachfolgende Anforderungen für die andere Version innerhalb des gleichen Anwendungspools nicht erfolgreich sind.

IIS erkennt, dass es sich bei dem Anwendungspool um die ASP.NET-Version handelt, unter der Sie eine Anwendung ausführen möchten. Folglich wird in der Anwendungspoolkonfiguration explizit die CLR- bzw. ASP.NET-Version konfiguriert, die im Anwendungspool geladen wird. Standardmäßig lädt IIS die durch diese Einstellung angegebene CLR beim Laden des Arbeitsprozesses vor (es sei denn, die Version ist als leerer Wert konfiguriert).

Da Anwendungspools die Grenze der .NET Framework-Versionsverwaltung darstellen, können Sie die Version einer ASP.NET-Anwendung wie folgt ändern:

1. Verschieben Sie die Anwendung in einen Anwendungspool, der die gewünschte ASP.NET-Version verwendet.
   Standardmäßig verwenden Anwendungen den Standardanwendungspool „DefaultAppPool“, der ASP.NET 2.1 im integrierten Modus ausführt. Verschieben Sie die Anwendung in den klassischen .NET-Anwendungspool (AppPool), um sie im klassischen Modus von ASP.NET 2.1 auszuführen (oder in einen anderen Anwendungspool Ihrer Wahl).
2. Konfigurieren Sie den Anwendungspool, in dem die Anwendung ausgeführt wird, für die Verwendung der gewünschten ASP.NET-Version.
   Standardmäßig sind alle neuen Anwendungspools so konfiguriert, dass ASP.NET 2.1 im integrierten Modus ausgeführt wird.

Hinweis

Verwenden Sie nicht die aspnet_regiis-Option „/i“ oder „/r“, um die Version von ASP.NET für eine bestimmte Anwendung (oder global) zu konfigurieren.

IIS verwendet vorkonfigurierte Handlerzuordnungen, um die korrekten Handlerzuordnungen auszuwählen (zu „ASPNET_isapi.dll“ im klassischen Modus oder direkt zu verwalteten Handlertypen im integrierten Modus). Dies ist abhängig von der konfigurierten CLR-Version sowie vom verwalteten Integrationsmodus des Anwendungspools. Das ASP.NET 2.0-Setup installiert diese Handlerzuordnungen auf der Serverebene.

Nutzen des integrierten ASP.NET-Modus

In IIS werden ASP.NET-Anwendungen standardmäßig im integrierten Modus ausgeführt. Wenn Sie jedoch die Vorteile nutzen möchten, die durch die engere Integration zur Verfügung stehen, sind einige Änderungen an der Anwendungskonfiguration erforderlich. Sie können auch neue ASP.NET-Komponenten entwickeln, die den integrierten Modus nutzen, um leistungsstarke Funktionen für Ihre Anwendung bereitzustellen.

Aktivieren von ASP.NET-Diensten für alle Inhaltstypen

Im integrierten Modus stehen Dienste, die von ASP.NET-Modulen bereitgestellt werden, für Anforderungen für alle Inhaltstypen zur Verfügung. Aus Gründen der Abwärtskompatibilität sind ASP.NET-Module standardmäßig jedoch so konfiguriert, dass sie nur für Anforderungen ausgeführt werden, die für ASP.NET-Inhalte bestimmt sind.

Fügen Sie für die einzelnen ASP.NET-Module im Konfigurationsabschnitt auf Serverebene jeweils eine Vorbedingung vom Typ „managedHandler“ an:

<modules> 
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
             preCondition="managedHandler" />
     <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" 
             preCondition="managedHandler" />
    ...
</modules>

Die Vorbedingung ist eine Regel, die der Server bei jeder Anforderung auswertet, um zu bestimmen, ob ein Modul ausgeführt wird. Die Vorbedingung „managedHandler“ gilt nur für Anforderungen an Inhaltstypen, die ASP.NET-Handlern zugeordnet sind.

Wenn Sie von einem ASP.NET-Modul bereitgestellte Funktionen auf alle Anforderungen anwenden möchten, entfernen Sie den Moduleintrag, und fügen Sie ihn dann ohne die Vorbedingung in der Stammdatei „Web.config“ der Anwendung wieder hinzu.

Wenn Sie die ASP.NET-Formularauthentifizierung für die gesamte Anwendung aktivieren möchten, ändern Sie die Datei „Web.config“ wie folgt:

<modules> 
    <remove name="FormsAuthentication" /> 
    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" /> 
    …
</modules>

Mit dieser Änderung wird das FormsAuthentication-Modul für alle Anforderungen in Ihrer Anwendung ausgeführt. Dadurch können Sie alle Anwendungsinhalte mit der Formularauthentifizierung schützen. Weitere Informationen zur Nutzung des integrierten Modus zur Bereitstellung der Formularauthentifizierung für alle Anwendungsinhalte finden Sie in der exemplarischen Vorgehensweise Nutzen der integrierten Pipeline von IIS 7.0.

Sie können auch eine Art Abkürzung verwenden, um die Ausführung aller verwalteten (ASP.NET-)Module für alle Anforderungen in Ihrer Anwendung unabhängig von der Vorbedingung „managedHandler“ zu aktivieren. Verwenden Sie die Eigenschaft runAllManagedModulesForAllRequests im Abschnitt <modules>, um die Ausführung aller verwalteten Module für alle Anforderungen zu aktivieren, ohne jeden Moduleintrag einzeln zu konfigurieren, um die Vorbedingung „managedHandler“ zu entfernen:

<modules runAllManagedModulesForAllRequests="true" />

Bei Verwendung dieser Methode hat die Vorbedingung „managedHandler“ keine Auswirkung, und alle verwalteten Module werden für alle Anforderungen ausgeführt.

Experimentieren Sie mit der Aktivierung anderer ASP.NET Module, die auf Ihre gesamte Anwendung angewendet werden sollen. Verwenden Sie z. B. das ASP.NET-Ausgabecachemodul, um einen Ausgabecache für ASP-Seiten zu nutzen, oder verwenden Sie die URL-Autorisierung und den Rollen-Manager, um Zugriffssteuerungsregeln für Ihre Fotos zu konfigurieren. Sie können auch ein eigenes Modul entwickeln, um die Leistungsfähigkeit von ASP.NET in Ihre gesamte Website zu integrieren.

Erstellen leistungsstärkerer ASP.NET-Dienste

Im integrierten Modus werden die Dienste von ASP.NET-Modulen auf alle Inhalte angewendet. Hinzu kommt: Da ASP.NET-Module in der vereinheitlichten Anforderungsverarbeitungspipeline im integrierten Modus ausgeführt werden, abonnieren sie die gleichen Anforderungsverarbeitungsphasen und führen die gleichen Aufgaben aus wie systemeigene Servermodule. Gleichzeitig bleiben ASP.NET-APIs bis auf einige wichtige Ergänzungen, die bislang nicht verfügbare Funktionen bereitstellen, weitgehend unverändert.

Laufzeittreue

Im integrierten Modus sind die ASP.NET-Anforderungsverarbeitungsphasen, die für Module verfügbar gemacht werden, direkt mit den entsprechenden Phasen der IIS-Pipeline verbunden. Die vollständige Pipeline enthält die folgenden Phasen, die in ASP.NET als HttpApplication-Ereignisse verfügbar gemacht werden:

1. BeginRequest. Die Verarbeitung von Anforderungen beginnt.
2. AuthenticateRequest. Die Anforderung wird authentifiziert. IIS- und ASP.NET-Authentifizierungsmodule abonnieren diese Phase, um die Authentifizierung durchzuführen.
3. PostAuthenticateRequest.
4. AuthorizeRequest. Die Anforderung ist autorisiert. IIS- und ASP.NET-Autorisierungsmodule überprüfen, ob der authentifizierte Benutzer Zugriff auf die angeforderte Ressource hat.
5. PostAuthorizeRequest.
6. ResolveRequestCache. Cachemodule überprüfen, ob die Antwort auf diese Anforderung im Cache vorhanden ist, und geben sie zurück, anstatt mit dem Rest des Ausführungspfads fortzufahren. Sowohl der ASP.NET-Ausgabecache als auch der IIS-Ausgabecache wird ausgeführt.
7. PostResolveRequestCache.
8. MapRequestHandler. Diese ASP.NET-interne Phase und wird verwendet, um den Anforderungshandler zu bestimmen.
9. PostMapRequestHandler.
10. AcquireRequestState. Der für die Anforderungsausführung erforderliche Zustand wird abgerufen. Die ASP.NET-Module „Sitzungszustand“ und „Profil“ rufen ihre Daten ab.
11. PostAcquireRequestState.
12. PreExecuteRequestHandler. Alle Aufgaben vor der Ausführung des Handlers werden ausgeführt.
13. ExecuteRequestHandler. Der Anforderungshandler wird ausgeführt. ASPX-Seiten, ASP-Seiten, CGI-Programme und statische Dateien werden bereitgestellt.
14. PostExecuteRequestHandler.
15. ReleaseRequestState. Die Anforderungszustandsänderungen werden gespeichert, und der Zustand wird bereinigt. Die ASP.NET-Module „Sitzungszustand“ und „Profil“ verwenden diese Phase für die Bereinigung.
16. PostReleaseRequestState.
17. UpdateRequestCache. Die Antwort wird für später im Cache gespeichert. Die Ausgabecachemodule von ASP.NET und IIS werden ausgeführt, um die Antwort im jeweiligen Cache zu speichern.
18. PostUpdateRequestCache.
19. LogRequest. In dieser Phase werden die Ergebnisse der Anforderung protokolliert. Sie wird auch im Falle von Fehlern garantiert ausgeführt.
20. PostLogRequest.
21. EndRequest. In dieser Phase wird eine ggf. erforderliche Anforderungsbereinigung durchgeführt. Sie wird auch im Falle von Fehlern garantiert ausgeführt.

Durch die Verwendung der vertrauten ASP.NET-APIs können Aufgaben, auf die bislang nur in systemeigenen ISAPI-Filtern und -Erweiterungen zugegriffen werden konnte, dank der Ausführung in den gleichen Phasen wie IIS-Module jetzt auch in verwaltetem Code verwendet werden.

Beispielsweise können Sie jetzt Module schreiben, die die folgenden Aktionen ausführen:

1. Abfangen der Anforderung vor jeglicher Verarbeitung, um beispielsweise URLs umzuschreiben oder eine Sicherheitsfilterung durchzuführen
2. Ersetzen integrierter Authentifizierungsmodi
3. Ändern der eingehende Anforderungsinhalte (beispielsweise Anforderungsheader)
4. Filtern ausgehender Antworten für alle Inhaltstypen

Ein gutes Beispiel für die Erweiterung von IIS mit einem benutzerdefinierten ASP.NET-Authentifizierungsmodul finden Sie unter Entwickeln von IIS 7.0-Modulen und -Handlern mit .NET Framework.

Erweiterte ASP.NET-APIs

Die ASP.NET-APIs sind weiterhin mit früheren Versionen abwärtskompatibel, sodass bereits vorhandene Module ohne Änderungen in IIS 7 und höheren Versionen funktionieren und ohne Codeänderungen auf alle Anwendungsinhalte angewendet werden können.

Module, die für den integrierten IIS-Modus geschrieben wurden, können jedoch einige zusätzliche APIs nutzen, um wichtige Anforderungsverarbeitungsszenarien zu ermöglichen, die zuvor nicht verfügbar waren.

Die neue Sammlung HttpResponse.Headers ermöglicht Modulen die Untersuchung und Bearbeitung von Antwortheadern, die von anderen Anwendungskomponenten generiert werden. Sie können beispielsweise den Content-Type-Header ändern, der von einer ASP-Seite generiert wird, um ein Downloaddialogfeld im Browser auszulösen. Die Cookies-Sammlung in der HttpResponse-Klasse wird ebenfalls verbessert, um Änderungen an Cookies zu ermöglichen, die im Rahmen der Anforderungsverarbeitung generiert werden. Das gilt auch, wenn sie außerhalb von ASP.NET erstellt wurden.

Die Sammlung HttpRequest.Headers unterstützt Schreibvorgänge, sodass Module die eingehenden Anforderungsheader bearbeiten können. Nutzen Sie dies, um das Verhalten anderer Serverkomponenten zu ändern. Sie können beispielsweise erzwingen, dass eine lokalisierte Anwendung eine Antwort in einer anderen Sprache an den Client zurückgibt, indem Sie den Wert des Accept-Language-Headers dynamisch ändern.

Außerdem unterstützt die Sammlung HttpRequest.ServerVariables jetzt Schreibvorgänge, wodurch IIS-Servervariablen festgelegt werden können. ASP.NET-Module nutzen diese Funktion, um von IIS bereitgestellte Werte zu ändern oder um neue Servervariablen zu erstellen, die für andere Anwendungsframeworks wie PHP sichtbar sind.

Laufzeitintegration

Zusätzlich zu den neuen APIs werden durch den integrierten Modus vorhandene ASP.NET-Funktionen aktiviert, um einen Mehrwert für Ihre Anwendung zu bieten.

Die von ASP.NET bereitgestellten Ablaufverfolgungsfunktionen (einschließlich der System.Diagnostics.Trace-Klasse und des Ablaufverfolgungsfeatures für ASP.NET-Seiten) geben jetzt Ablaufverfolgungsinformationen an das IIS-Ablaufverfolgungssystem aus. Dadurch können die Ablaufverfolgungsinformationen, die im Zuge der Anforderungsverarbeitung sowohl von IIS- als auch von ASP.NET-Komponenten generiert werden, in einer einzelnen Protokolldatei platziert werden, was eine bessere Diagnose von Serverproblemen ermöglicht.

Die ASP.NET-Antwortfilterung, mit deren Hilfe Antworten unter Verwendung einer Streamschnittstelle geändert werden können, bevor sie an den Client weitergegeben werden, wurde verbessert, um das Filtern ASP.NET-fremder Inhalte zu ermöglichen. Dadurch können Sie die ASP.NET-Filterung für alle Serverinhalte verwenden oder den Filter selektiv für bestimmte Anforderungen für Inhalte installieren, die Sie verarbeiten möchten. Dies ermöglicht es Ihnen, Filterfeatures zu schreiben, die bestimmte Inhalte in die Antworten der Site einfügen oder in den Antworten zensieren – unabhängig davon, ob der betreffende Inhalt von einer ASPX-Seite oder aus einer statischen Datei stammt.

Zusammenfassung

Durch die ASP.NET-Integration in IIS 7 und höhere Versionen können Entwickler das Potenzial von ASP.NET voll ausschöpfen und leistungsstarke Serverkomponenten mit der Einfachheit und dem Umfang von ASP.NET und .NET Framework entwickeln. Weitere Informationen zur Nutzung des integrierten ASP.NET-Modus für bereits vorhandene Anwendungen finden Sie unter Nutzen der integrierten Pipeline von IIS 7.0. Informationen zur Erstellung neuer ASP.NET-Komponenten, um den Server zu erweitern, finden Sie unter Entwickeln von IIS 7.0-Modulen und -Handlern mit .NET Framework.