Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
vom IIS-Team
Einführung
Für ASP.NET-Anwendungsentwickler, die auf Windows Vista™ oder auf ein höheres Windows-Betriebssystem umsteigen, stellen IIS 7.0 und höhere Versionen einen erheblichen Fortschritt gegenüber früheren IIS-Versionen dar. Der integrierte IIS-Modus bietet unter anderem verbesserte Sicherheit und neue Anwendungsmöglichkeiten.
Die meisten Entwickler, die auf Windows Vista umsteigen, führen ein Upgrade vom Microsoft Windows® XP-Betriebssystem auf Windows Vista durch und upgraden dabei auch ihre ASP.NET-Anwendungen. Alternativ installieren sie unter Windows Vista die ASP.NET-Anwendungen, die sie unter anderen Windows-Betriebssystemen entwickelt haben.
In diesem Dokument werden wichtige Konfigurationsschritte erläutert, die nach der Installation bzw. nach dem Upgrade ausgeführt werden müssen, damit Anwendungen unter dem neuen Betriebssystem funktionieren. Es beschreibt Änderungen zwischen dem klassischen Modus und dem integrierten IIS-Modus, die sich auf ASP.NET-Anwendungen auswirken, und Sie erfahren, wie Sie diese bekannten Probleme umgehen können.
Eine der wesentlichen Verbesserungen ab IIS 7.0 ist eine integrierte Pipeline, die Webanwendungen die Verwendung einer einzelnen Anforderungsverarbeitungspipeline aus verwalteten oder nicht verwalteten Codeanwendungen ermöglicht. Darüber hinaus reduziert das neue Pipelinemodell redundantes Verhalten, das sich aus zwei separaten Implementierungen des gleichen Features ergibt.
In früheren Releases wurden von IIS und ASP.NET beispielsweise separate Anforderungspipelines ohne gemeinsamen Zugriff auf Ereignisse und Handlermodule implementiert. Die Authentifizierung wurde unabhängig in jeder Pipeline durchgeführt. Im neuen Modell kann die Authentifizierung einmalig für IIS und ASP.NET durchgeführt werden.
Im Anschluss finden Sie noch einige weitere Vorteile dieser Integration:
- ASP.NET-Dienste wie Formularauthentifizierung und Rollen, die mit IIS-Inhaltstypen arbeiten (z. B. statische und klassische ASP-Seiten)
- IIS-Funktionen, die mit verwaltetem Code und mit ASP.NET-Pipelinemodulen erweitert werden, anstatt nur mit ISAPI-Erweiterungen oder CGI
- Vereinfachte Problembehandlung dank der Integration von Ereignisablaufverfolgung und Fehlerprotokollierung
- Gemeinsame Verwendung der Anwendungskonfiguration zwischen ASP.NET und IIS
In diesem Artikel werden Kompatibilitätsprobleme für ASP.NET-Anwendungen untersucht, die von früheren IIS-Versionen zu IIS 7.0 und höheren Versionen migriert werden. Dabei stehen insbesondere die Unterschiede im Mittelpunkt, die mit der Umstellung vom klassischen Modus auf die Verwendung der integrierten Pipeline im integrierten Modus zusammenhängen.
Eine vollständige Übersicht über die Features und Vorteile der Integration von ASP.NET und IIS finden Sie im Artikel ASP.NET-Integration in IIS 7.
Upgraden von früheren IIS-Versionen auf Windows Vista
Das folgende Diagramm zeigt die Verfügbarkeit von IIS 7.0 in den verfügbaren Versionen von Windows Vista:
| Windows Vista-Version | IIS 7.0-Verfügbarkeit |
|---|---|
| Home Basic | N |
| Home Premium | J |
| Unternehmen | J |
| Ultimate | J |
ASP.NET-Upgradeszenarien unter Windows Vista
Die folgende Tabelle enthält eine kurze Übersicht über die unterstützten Upgradepfade für ASP.NET in früheren Versionen von Windows-Betriebssystemen zu ASP.NET unter Windows Vista. In Fällen, in denen auf Probleme hingewiesen wird, finden Sie in den folgenden Abschnitten weitere Informationen zu Upgradeeinschränkungen.
Die Tabelle zeigt auch, dass keine Upgrades von Serverbetriebssystemversionen auf Clientbetriebssystemversionen verfügbar sind. Stattdessen müssen Sie auf einem Computer, auf dem derzeit ein Serverbetriebssystem installiert ist, eine Neuinstallation von Vista durchführen.
| Operating System (Betriebssystem) | IIS-Version | .NET Framework-Version | Überlegungen beim Upgraden auf Windows Vista/IIS 7.0 |
|---|---|---|---|
| Windows 2000 Server | IIS 5.0 | 1.0, 1.1, 2.0 | Kein Upgrade auf Windows Vista verfügbar |
| Windows 2000 Professional | IIS 5.0 | 1.0, 1.1, 2.0 | Neuinstallation des Betriebssystems erforderlich |
| Windows Server 2003 | IIS 6.0 | 1.0, 1.1, 2.0 | Kein Upgrade auf Windows Vista verfügbar |
| Windows XP Home | N/V | 1.0, 1.1, 2.0 | IIS war in Windows XP enthalten. Unter Windows Vista können Benutzer IIS 7.0 oder eine höhere Version installieren. |
| Windows XP Professional | IIS 5,1 | 1.0 | .NET Framework 1.0 wird unter Windows Vista unterstützt. ASP.NET 1.0-Anwendungen müssen mindestens auf ASP.NET 1.1 aktualisiert werden. (ASP.NET 2.0 wird empfohlen.) |
| 1.1 | Manuelle Konfiguration nach dem Upgrade erforderlich (siehe weiter unten in diesem Artikel) | ||
| 2.0 | Nach einem Upgrade muss ASP.NET in den IIS-Setupoptionen ausgewählt werden, um ASP.NET 2.0 im integrierten Modus zu konfigurieren. | ||
| Windows XP Tablet PC | IIS 5,1 | 1.0 | .NET Framework 1.0 wird unter Windows Vista unterstützt. ASP.NET 1.0-Anwendungen müssen mindestens auf ASP.NET 1.1 aktualisiert werden. (ASP.NET 2.0 wird empfohlen.) |
| 1.1 | Manuelle Konfiguration nach dem Upgrade erforderlich (siehe weiter unten in diesem Artikel) | ||
| 2.0 | Nach einem Upgrade muss ASP.NET in den IIS-Setupoptionen ausgewählt werden, um ASP.NET 2.0 im integrierten Modus zu konfigurieren. | ||
| Windows XP Professional x64 | IIS 5,1 | 1.1, 2.0 | Neuinstallation des Betriebssystems erforderlich |
Anwendungskonfiguration nach der Installation
Unmittelbar nach einer Installation oder eines Upgrades auf Windows Vista müssen Benutzer zusätzliche Konfigurationsschritte ausführen, damit Anwendungen funktionieren. Die Konfigurationsschritte nach der Installation hängen von der ASP.NET-Version ab, die von der jeweiligen Anwendung verwendet wird.
Konfigurieren von ASP.NET 1.1-Anwendungen
Vor der Installation von .NET Framework 1.1 (die erforderlich ist, wenn Sie ASP.NET 1.1-Anwendungen ausführen) müssen Benutzer die beiden folgenden Schritte ausführen, um ASP.NET-Anwendungen zu aktivieren:
Prozedur
Jeder IIS-Anwendungspool, in dem eine ASP.NET-Anwendung ausgeführt wird, muss explizit unter Verwendung der .NET Framework-Version konfiguriert werden, die der Version von ASP.NET entspricht, die für die Anwendung verwendet wurde. Pro Anwendungspool kann nur eine einzelne Version von ASP.NET ausgeführt werden. Daher müssen separate Anwendungspools für die einzelnen ASP.NET-Versionen verwendet werden.
Öffnen Sie in der IIS-Manager-Konsole die Option „Anwendungspools“, klicken Sie mit der rechten Maustaste auf einen Anwendungspool, und wählen Sie „Grundeinstellungen“ aus. Wählen Sie im Dialogfeld „Anwendungspool bearbeiten“ (Abbildung 1) die .NET Framework-Version aus, die den im Anwendungspool konfigurierten Anwendungen entspricht, und klicken Sie anschließend auf „OK“.
Abbildung 1: Bearbeiten der Anwendungspooleinstellungen
Verwenden von ASP.NET 1.1 im klassischen Modus
ASP.NET 1.1 verwendet im klassischen Modus eine IIS-ISAPI-Erweiterung. Dies ist die Standardeinstellung für ASP.NET nach einer Installation oder einem Upgrade. (Beachten Sie, dass ASP.NET 2.0 auch im integrierten Modus unter Windows Vista ausgeführt werden kann, wofür keine ISAPI-Erweiterung erforderlich ist.)
Sie müssen explizit die Ausführung der von Ihren Anwendungen verwendeten ASP.NET-Version zulassen. Verwenden Sie hierzu die Konfiguration „ISAPI- und CGI-Einschränkungen“ in der IIS-Verwaltungskonsole. Öffnen Sie den IIS-Manager, und wählen Sie „ISAPI- und CGI-Einschränkungen“ aus. Wählen Sie auf der Seite „ISAPI- und CGI-Einschränkungen“ alle Versionen von ASP.NET aus, die in der Spalte „Einschränkung“ auf „Nicht zugelassen“ festgelegt sind, und klicken Sie im rechten Bereich der Seite auf den Link „Zugelassen“, um die Einstellung entsprechend zu ändern.
Abbildung 2 zeigt ein Beispiel für die Seite „ISAPI- und CGI-Einschränkungen“, auf der die Version der Assembly „Aspnet_isapi.dll“ ausgewählt ist, die für ASP.NET 1.1 verwendet wird. In diesem Fall muss die Einstellung für diese ISAPI-Erweiterung von „Nicht zugelassen“ in „Zugelassen“ geändert werden.
Abbildung 2: Liste der ISAPI- und CGI-Einschränkungen
Konfigurieren von ASP.NET 2.0-Anwendungen
.NET Framework 2.0 wird im Rahmen der Windows Vista-Installation installiert. Daher ist ASP.NET 2.0 nach der Installation bereits auf dem Server vorhanden. Um die ASP.NET-Konfiguration unter Vista für ASP.NET 2.0-Anwendungen abzuschließen, müssen Benutzer allerdings noch die beiden folgenden Schritte ausführen:
Schritt 1
Wählen Sie im Paket-Manager von Windows Vista (unter „Systemsteuerung“ > „Programme und Features“ > „Windows-Features aktivieren oder deaktivieren“) die Option „ASP.NET“ aus, wie in Abbildung 3 dargestellt, und klicken Sie auf „OK“.
Hinweis
Wenn ASP.NET bereits vor diesem Schritt auf dem Computer installiert ist, wird durch Auswählen von „ASP.NET“ auf diese Weise sichergestellt, dass zusätzliche Konfigurationsschritte abgeschlossen sind.
Abbildung 3: Windows Vista-Installation: Windows-Features
Schritt 2
Jeder IIS-Anwendungspool, in dem eine ASP.NET-Anwendung ausgeführt wird, muss explizit unter Verwendung der .NET Framework-Version konfiguriert werden, die der Version von ASP.NET entspricht, die für die Anwendung verwendet wurde. Pro Anwendungspool kann nur eine einzelne Version von ASP.NET ausgeführt werden. Daher müssen separate Anwendungspools für die einzelnen ASP.NET-Versionen verwendet werden.
Öffnen Sie im IIS-Manager die Option „Anwendungspools“, klicken Sie mit der rechten Maustaste auf einen Anwendungspool, und wählen Sie „Grundeinstellungen“ aus. Wählen Sie im Dialogfeld „Anwendungspool bearbeiten“ (Abbildung 4) die .NET Framework-Version aus, die den im Anwendungspool konfigurierten Anwendungen entspricht, und klicken Sie anschließend auf „OK“.
Abbildung 4: Anwendungspool und integrierter Modus
Anwendungspooleinstellungen
Wenn für ASP.NET-Anwendungen unter früheren Versionen von Windows-Betriebssystemen ein Upgrade auf Windows Vista durchgeführt wird, werden sie basierend auf IIS-Anwendungsisolationseinstellungen wie folgt in Anwendungspools konfiguriert:
| IIS-Isolationskonfiguration vor dem Upgrade | IIS-Anwendungspool | Identität des IIS-Anwendungspools |
|---|---|---|
| Niedrig | AppPool niedrig | NT AUTHORITY\NETWORK SERVICE |
| Medium | AppPool mittel | IWAM_<Computername> |
| Hoch | Anwendungen werden in einem Anwendungspool konfiguriert, der dem Anwendungsnamen entspricht. | IWAM_<Computername> |
Keine Unterstützung von ASP.NET v1.0 unter Windows Vista
.NET Framework 1.0 wird unter Windows Vista nicht unterstützt. Daher muss für ASP.NET 1.0-Anwendungen mindestens ein Upgrade auf ASP.NET 1.1 durchgeführt werden. Es wird dringend empfohlen, für Ihre ASP.NET 1.0-Anwendungen ein Upgrade auf ASP.NET 2.0 durchzuführen, um von der besseren Leistung und Verwaltbarkeit der höheren Versionen von ASP.NET zu profitieren.
HTTP-Handler
Bei einem Upgrade auf IIS 7.0 und höhere Versionen unter Windows Vista werden nur vorkonditionierte, auf globaler Ebene konfigurierte HTTP-Handler aktualisiert. Auf Standortebene konfigurierte Handler werden nicht aktualisiert.
Unterstützung der parallelen Ausführung
Anwendungen, die in verschiedenen Versionen von ASP.NET (z. B. 1.1 und 2.0) entwickelt wurden, können parallel in IIS ausgeführt werden. Sie müssen Anwendungen in einem IIS-Anwendungspool konfigurieren. Dieser Pool muss für die Version von ASP.NET konfiguriert werden, für die die Anwendung entwickelt wurde. Pro Anwendungspool kann nur eine einzelne ASP.NET-Version konfiguriert werden.
Für .NET Framework 1.1: WOW 64-Konfiguration unter 64-Bit-Version von Windows Vista erforderlich
ASP.NET ist nicht ordnungsgemäß eingerichtet, wenn .NET Framework 1.1 unter 64-Bit-Versionen von Windows Vista installiert ist. Nach der Installation von .NET Framework 1.1 unter 64-Bit-Versionen von Windows Vista müssen Anwendungen manuell mithilfe des IIS-Verwaltungstools auf globaler Ebene so konfiguriert werden, dass sie mit WOW 64 ausgeführt werden.
Konfigurieren des von einer Anwendung verwendeten Pipelinemodus
IIS ist für die Verwendung des neuen integrierten Modus für neue Anwendungen konfiguriert. Dies ist die Standardeinstellung. Der Pipelinemodus wird mithilfe der Anwendungspooleinstellungen konfiguriert. Ändern Sie diese Einstellungen mithilfe einer der folgenden Optionen:
- IIS-Verwaltungstool
- Befehlszeilentool „APPCMD.EXE“
- Bearbeitung der Anwendungskonfigurationsdatei mit einem Text-Editor
Wenn Sie für einen bereits vorhandenen Computer ein Upgrade auf IIS 7.0 oder auf eine höhere durchführen, werden die Anwendungen standardmäßig so konfiguriert, dass sie im klassischen Modus ausgeführt werden. Der klassische Modus bietet Kompatibilität für Anwendungen mit spezifischen Abhängigkeiten von der Implementierung der HTTP-Pipeline in früheren IIS-Versionen.
Wenn Sie allerdings eine bereits vorhandene Anwendung auf einem Computer importieren, auf dem mindestens IIS 7.0 ausgeführt wird, und Sie die Website kopieren, wird der verwendete Pipelinemodus durch die Einstellungen des Anwendungspools bestimmt, in dem die Anwendung für die Ausführung konfiguriert ist.
Wenn Sie die Anwendung also beispielsweise auf Ihren Computer kopieren und so konfigurieren, dass sie im Standardanwendungspool ausgeführt wird, wird sie mit den Einstellungen dieses Anwendungspools ausgeführt, die standardmäßig auf den integrierten Modus festgelegt sind. Wenn Sie den Pipelinemodus für Ihre Anwendung ändern möchten, ändern Sie entweder die Einstellungen für den Standardanwendungspool, oder erstellen Sie einen neuen Anwendungspool mit den gewünschten Einstellungen.
Weitere Informationen zum Konfigurieren einer bereits vorhandenen Anwendung für die Verwendung des integrierten Modus finden Sie im Artikel ASP.NET-Integration in IIS 7 im Abschnitt „Migrieren von ASP.NET-Anwendungen zu IIS 7 und höheren Versionen (integrierter Modus)“. Dort finden Sie eine Anleitung zum Ändern der Anwendungskonfigurationseinstellungen.
Kompatibilität
ASP.NET-Pipelinemodule, die für frühere Versionen von IIS entwickelt wurden und später für die Verwendung des integrierten Modus mit IIS 7.0 und höheren Versionen konfiguriert werden, können sich unterschiedlich verhalten oder andere Kompatibilitätsprobleme aufweisen. Solche Probleme werden durch die Architekturunterschiede zwischen der Pipeline in früheren IIS-Versionen und im modularen Entwurf ab IIS 7.0 und der integrierten HTTP-Pipeline verursacht.
In den weiteren Abschnitten dieses Artikels werden mögliche Kompatibilitätsprobleme für Anwendungen beschrieben und Problemumgehungen vorgeschlagen. Wenn sich eine vorgeschlagene Problemumgehung nicht implementieren lässt, konfigurieren Sie Ihre Anwendung so, dass sie im klassischen Modus ausgeführt wird, um das Kompatibilitätsproblem zu vermeiden.
Bekannte Unterschiede zwischen integriertem und klassischem Modus
Hier finden Sie eine Liste mit bekannten Problemen zwischen den beiden Modi. Lesen Sie sich diese Liste sorgfältig durch.
Im integrierten Modus wird „Application_OnError“ nicht für Ausnahmen aufgerufen, die in „HttpApplication::Init“ auftreten.
Im integrierten Modus können Ausnahmen, die während der Initialisierung einer Anwendung oder eines Moduls auftreten, nicht mithilfe des Application.Error-Ereignisses abgefangen werden.
Außerdem können Anwendungen, die „Server.ClearError“ zur Wiederherstellung nach Fehlern verwenden, während der Anwendungsinitialisierung keine Fehler löschen. Dadurch wird verhindert, dass eine Anwendung einen Fehler während der Initialisierung ignoriert. Anwendungen, die Fehlerinformationen für jede auftretende Ausnahme protokollieren, können die Fehler, die während der Anwendungsinitialisierung auftreten, nicht protokollieren, obwohl diese Fehler mithilfe von Webereignissen und HTTP-Antworten gemeldet werden.
Wenn bei einer Anwendung eine solche Ausnahmenbehandlung während der Initialisierung implementiert werden muss, muss sie im klassischen Modus (nicht im integrierten Modus) ausgeführt werden.
Ausnahmemeldung wird im integrierten Modus nicht durch „Server.ClearError“ in „EndRequest“ gelöscht.
Im integrierten Modus wird die Ausnahmeantwort durch Aufrufen von „Server.ClearError“ in „EndRequest“ nicht gelöscht, wenn zu einem früheren Zeitpunkt der Anforderungsverarbeitung eine Ausnahme aufgetreten ist. Anwendungen, die die Ausnahmemeldung in „EndRequest“ löschen, können die Ausnahmeausgabe nicht aus der Antwort entfernen.
Wenn bei einer Anwendung eine solche Ausnahmenbehandlung im Rahmen von „EndRequest“ implementiert werden muss, muss sie im klassischen Modus (nicht im integrierten Modus) ausgeführt werden.
Anwendungen im integrierten Modus können eine Antwort in „EndRequest“ schreiben, nachdem eine Ausnahme formatiert und in die Antwort geschrieben wurde.
Im integrierten Modus ist es möglich, eine zusätzliche Antwort zu schreiben und anzuzeigen, die nach dem Auftreten einer Ausnahme geschrieben wurde.
Im klassischen Modus kommt diese Situation nicht vor. Wenn während der Anforderung ein Fehler auftritt und die Anwendung nach Auftreten der Ausnahme etwas in die Antwort in „EndRequest“ schreibt, werden die in „EndRequest“ geschriebenen Antwortinformationen angezeigt. Dies betrifft nur Anforderungen mit unbehandelten Ausnahmen.
Um Schreibvorgänge in die Antwort nach einer Ausnahme zu vermeiden, muss eine Anwendung „HttpContext.Error“ oder „HttpResponse.StatusCode“ überprüfen, bevor sie etwas in die Antwort schreibt.
Im integrierten Modus unterdrückt ASP.NET den Inhaltstyp nicht mehr, wenn die Antwort leer ist.
Im integrierten Modus generieren ASP.NET-Handler Content-Type-Header, wenn dies explizit von einem Modul festgelegt wurde – auch wenn die Antwort leer ist. Einige Anwendungen generieren einen Inhaltstyp für leere Antworten. Ändern Sie ggf. Anwendungen, um den Content-Type-Header explizit zu entfernen, indem Sie ihn auf NULL festlegen.
Unterschiedliche Windows-Identität in der Formularauthentifizierung
Wenn die Formularauthentifizierung von einer Anwendung verwendet und anonymer Zugriff zugelassen wird, unterscheidet sich die Identität des integrierten Modus wie folgt von der Identität des klassischen Modus:
- „ServerVariables["LOGON_USER"]“ ist gefüllt.
- „Request.LogonUserIdentity“ verwendet Anmeldeinformationen des Kontos „[NT AUTHORITY\NETWORK SERVICE]“ anstelle des Kontos „[NT AUTHORITY\INTERNET USER]“.
Dieses Verhalten tritt auf, da die Authentifizierung im integrierten Modus in einer einzelnen Phase erfolgt. Im klassischen Modus erfolgt die Authentifizierung dagegen zuerst mit IIS unter Verwendung von anonymem Zugriff und dann mit ASP.NET unter Verwendung der Formularauthentifizierung. Daher ist das Ergebnis der Authentifizierung immer ein einzelner Benutzer: der Benutzer der Formularauthentifizierung. „AUTH_USER/LOGON_USER“ gibt diesen Benutzer zurück, da die Anmeldeinformationen der Formularauthentifizierung zwischen IIS und ASP.NET synchronisiert werden.
Ein Nebeneffekt ist, dass „LOGON_USER“, „HttpRequest.LogonUserIdentity“ und der Identitätswechsel nicht mehr auf die anonymen Benutzeranmeldeinformationen zugreifen können, die von IIS mithilfe des klassischen Modus authentifiziert worden wären.
Authentication_OnAuthenticate-Standardereignis wird im integrierten Modus nicht ausgelöst.
Im integrierten Modus wird das DefaultAuthenticationModule.Authenticate-Ereignis nicht mehr ausgelöst. Im klassischen Modus wird dieses Ereignis ausgelöst, wenn keine Authentifizierung erfolgt ist. Im integrierten Modus erhält eine Anwendung, bei der der Authentifizierungsmodus auf „None“ festgelegt ist und die das DefaultAuthentication.Authenticate-Ereignis abonniert hat, eine Ausnahme, die angibt, dass dieses Feature im integrierten Modus nicht unterstützt wird. Authentifizierungsschemas, die auf diesem Muster basieren, funktionieren nicht.
Um diese Änderung zu umgehen, können Anwendungen im integrierten Modus stattdessen „AuthenticateRequest“ abonnieren.
Im integrierten Modus enthält „Request.RawUrl“ nach dem Aufruf von „RewritePath“ die neue Abfragezeichenfolge.
Im integrierten Modus enthält die Request.RawUrl-Eigenschaft die neue Abfragezeichenfolge, nachdem „RewritePath“ für eine URL mit einer neuen Abfragezeichenfolge aufgerufen wurde. Im klassischen Modus enthält sie die alte Abfragezeichenfolge.
Schreiben Sie Ihre Anwendung um, damit sie nicht von dem alten Verhalten abhängt, um diese Änderung zu umgehen.
Die Authentifizierung mit Passport-Netzwerkanmeldeinformationen wird unter Windows Vista nicht unterstützt.
Die Funktionen für Passport-Netzwerkanmeldeinformationen wurden aus Windows Vista und aus dem Microsoft Windows Server® 2008-Betriebssystem entfernt. Daher funktioniert die Authentifizierung mit Passport-Netzwerkanmeldeinformationen in ISAPI und im integrierten Modus standardmäßig nicht.
Das PassportAuthentication-Modul ist nicht Teil der integrierten Pipeline.
Im integrierten Modus wird das ASP.NET-Modul für die Passport-Authentifizierung standardmäßig aus der Pipeline entfernt. Wenn es von einer Anwendung verwendet wird, kann es der Pipeline wieder hinzugefügt werden. Wie bereits erwähnt, wurden die Funktionen für Passport-Netzwerkanmeldeinformationen aus Windows Vista und aus Microsoft Windows Server 2008 entfernt. Daher funktioniert die Authentifizierung mit Passport-Netzwerkanmeldeinformationen in ISAPI und im integrierten Modus standardmäßig nicht.
Große, gültige Formularauthentifizierungstickets (Länge <= 4.096 Bytes) in der Abfragezeichenfolge werden von IIS 7.0 und höheren Versionen abgelehnt.
IIS lehnt Anforderungen mit großen cookielosen ASP.NET-Tickets ab, wie sie beispielsweise in der Formularauthentifizierung, im Sitzungszustand und in der anonymen ID verwendet werden, wenn diese insgesamt größer als 4.096 Bytes sind. Diese Einschränkung gilt aus Sicherheitsgründen und verhindert Pufferüberlauf-Exploits mit großen Abfragezeichenfolgen. Bei Anwendungen, die benutzerdefinierte Daten speichern oder sehr große Benutzernamen in Formularauthentifizierungstickets verwenden, kommt es ggf. zur Ablehnung von Anforderungen, da die Abfragezeichenfolgen zu groß sind.
Passen Sie zur Änderung dieses Verhaltens die maximale Größe der Abfragezeichenfolge im Abschnitt mit der Konfiguration der IIS-Anforderungsfilterung an.
Im integrierten Modus wird das ASP.NET-Anforderungstimeout während der Anforderung mehrmals angewendet, sodass die Anforderung länger ausgeführt werden kann.
Im integrierten Modus wird das verwaltete Timeout für die Ausführung von Anforderungen für jeden neuen Übergang in der Pipeline zurückgesetzt. Das bedeutet, dass die Anforderung bis zu (Timeout × Anzahl von Modulbenachrichtigungen) verwenden kann, solange ein einzelnes Timeout nicht die für ein Timeout festgelegte maximale Zeit übersteigt.
Langsame Anforderungen werden möglicherweise nicht abgebrochen oder dauern erheblich länger – je nach Anzahl der ASP.NET-Module und der Qualität der Zusammenführung der Module. Vermeiden Sie dieses Verhalten, indem Sie die Einstellung für die Timeout-Dauer auf einen niedrigeren Wert festlegen.
Ablaufverfolgungseinstellungen werden nicht an die Server.Transfer-Zielseite übertragen.
Im integrierten Modus wird keine Übertragung von Ablaufverfolgungseinstellungen an das Ziel eines Server.Transfer-Vorgangs unterstützt.
Die Methode „Httpcontext.Current.Response.Write()“ funktioniert in „Application_Onstart()“ nicht.
Im integrierten Modus kann eine Anwendung „http.Current.Response.Write()“ nicht in einer Application_Onstart()-Methode aufrufen.
Wenn vor „PostAuthenticateRequest“ auf „HttpRequest.LogonUserIdentity“ zugegriffen wird, wird eine Ausnahme ausgelöst.
Im integrierten Modus löst die HttpRequest.LogonUserIdentity-Eigenschaft eine Ausnahme aus, wenn auf sie vor „PostAuthenticateRequest“ zugegriffen wird. Wenn ein Modul vor „PostAuthenticateRequest“ auf diese Eigenschaft zugreift, wird eine Ausnahme ausgelöst.
Greifen Sie zur Vermeidung dieses Verhaltens in Ihrer Anwendung nicht auf diese Eigenschaft zu, oder greifen Sie erst nach Abschluss von „PostAuthenticateRequest“ darauf zu.
Im integrierten Modus erhalten ASP.NET-Module die erste nicht authentifizierte Anforderung für IIS 7.0 und höhere Versionen, wenn die anonyme Authentifizierung deaktiviert ist.
Wenn im integrierten Modus ein anderes IIS-Authentifizierungsschema als die anonyme Authentifizierung verwendet wird, ist die erste Anforderung des Clients, die nicht die erforderlichen Anmeldeinformationen enthält, für ASP.NET-Module in den Phasen „BeginRequest“ und „AuthenticateRequest“ sichtbar.
Im klassischen Modus ist eine derartige Anforderung für eine ASP.NET-Anwendung nicht sichtbar, da IIS sie mit einer 401-Meldung ablehnt, bevor sie von ASP.NET verarbeitet werden kann.
Das bedeutet, dass für ASP.NET-Module in den Phasen „BeginRequest“ und „AuthenticateRequest“ eine zusätzliche Anforderung vorhanden ist. Die Anforderung wird in Webereignissen und in jeder benutzerdefinierten Protokollierung angezeigt, die ggf. in „BeginRequest“ oder „EndRequest“ durchgeführt wird.
ASP.NET kann die Clientidentität erst nach Ausführung von „PostAuthenticateRequest“ annehmen.
Im integrierten Modus übernimmt ASP.NET die Identität des Clients erst nach Auftreten von „PostAuthenticateEvent“, wenn die Annahme der Clientidentität für eine Anwendung mit „Web.config“ der Anwendung oder in „Machine.config“ aktiviert ist.
Bei aktivierter Annahme der Clientidentität werden außerdem Module, die in den BeginRequest- und AuthenticateRequest-Ereignissen ausgeführt werden, mit der Prozessidentität statt mit der Identität des authentifizierten Benutzers ausgeführt. Dies sollte kein Problem darstellen, da Module selten auf Ressourcen in diesen Ereignissen zugreifen, weil der authentifizierte Benutzer noch nicht eingerichtet wurde.
Andernfalls wird jedoch die Prozessidentität für den Zugriff auf Ressourcen verwendet.
Aufgrund der möglichen Erhöhung von Benutzerrechten, die diese Änderung verursachen kann, löst IIS eine Ausnahme aus, wenn die Annahme der Clientidentität aktiviert ist. Das bedeutet, dass die Anwendung entweder zum klassischen Modus migriert oder dieser Fehler deaktiviert werden muss, wenn bestätigt werden kann, dass auf Ressourcen in den BeginRequest- oder AuthenticateRequest-Ereignissen zugegriffen wird.
Wenn Zeichensatz und Inhaltstyp auf eine leere Zeichenfolge festgelegt sind, wird kein Content-Type-Header generiert.
„HTTP.sys“ generiert den Content-Type-Header nicht mehr, wenn er explizit auf „String.Empty“ festgelegt ist. Anwendungen, deren Clients auf einen leeren Content-Type-Header angewiesen sind, können von dieser Änderung betroffen sein.
Im integrierten Modus werden sowohl synchrone als auch asynchrone Ereignisse für die einzelnen Module ausgelöst, bevor das nächste Modul ausgeführt wird.
Im integrierten Modus werden sowohl synchrone als auch asynchrone Ereignisse für die einzelnen Module ausgelöst, bevor der Server zum nächsten Modul übergeht.
Dies unterscheidet sich vom klassischen Modus, in dem zuerst alle asynchronen Modulbenachrichtigungen und dann alle synchronen Benachrichtigungen ausgeführt werden. Dies sollte keine Auswirkung auf Anwendungen haben, solange keine Abhängigkeit von der Reihenfolge besteht. (Weitere Informationen finden Sie an anderer Stelle in diesem Dokument unter „Bei Verwendung des integrierten Modus ist die Reihenfolge der Module für „PreSendRequestHeaders“ und „PreSendRequestContent“ umgekehrt.“.)
Antwortheader werden im integrierten Modus entfernt, nachdem „ClearHeader“ in einem benutzerdefinierten Modul vom Typ „IHttpModule“ aufgerufen wurde.
Im integrierten Modus generiert ein Aufruf von „ClearHeaders“ nicht automatisch Standardheader. Anwendungen, die „ClearHeaders“ aufrufen, um die Header für eine ASPX-Seite wieder in den Standardzustand zu versetzen, löschen stattdessen alle Antwortheader.
Die gemeinsame Verwendung von Windows- und Formularauthentifizierung wird im integrierten Modus nicht unterstützt.
Im integrierten Modus werden das Festlegen von „Impersonate=true“ und die Verwendung der Formularauthentifizierung nicht unterstützt und verursachen einen Fehler oder ein falsches Verhalten.
Im integrierten Modus werden neue Zeilen in Antwortheadern ab IIS 7.0 immer abgelehnt (auch wenn „enableHeaderChecking“ von ASP.NET auf „false“ festgelegt ist).
Im integrierten Modus wird eine Ausnahme ausgelöst, wenn Sie versuchen, einen Antwortheader auf einen Wert festzulegen, der „\r“ oder „\n“ enthält. Im klassischen Modus wird dieser Wert standardmäßig codiert und übergeben, wenn die Headercodierung deaktiviert ist. Aus Sicherheitsgründen sollten Anwendungen nicht versuchen, in Headerwerten uncodierte neue Zeilen zu schreiben.
PreSendRequestHeaders- und PreSendRequestContent-Ereignisse werden gemeinsam für jedes Modul ausgelöst.
Im integrierten Modus werden Module, die PreSendRequestHeaders- und PreSendRequestContent-Ereignisse abonnieren, gemeinsam für die PreSendRequestHeaders- und PreSendRequestContent-Ereignisse benachrichtigt.
Es kann beispielsweise vorkommen, dass eine Anwendung nicht mehr funktioniert, wenn Modul A davon abhängig ist, dass Modul B in „PreSendRequestHeaders“ ausgeführt wird, bevor Modul A für „PreSendRequestContent“ ausgeführt wird – etwa, wenn Modul B einen Anforderungszustand ändert und Modul A davon abhängig ist.
Bei Verwendung des integrierten Modus ist die Reihenfolge der Module für „PreSendRequestHeaders“ und „PreSendRequestContent“ umgekehrt.
Im integrierten Modus werden Module, die „PreSendRequestHeaders“ und „PreSendRequestContent“ abonnieren, in umgekehrter Reihenfolge ihres Vorkommens im Abschnitt benachrichtigt. Anwendungen mit mehreren Modulen, die für die Ausführung in einem dieser Ereignisse konfiguriert sind, sind von dieser Änderung betroffen, wenn sie gemeinsam von der Ereignisreihenfolge abhängig sind.
Ändern Sie zur Umgehung solcher Probleme entweder die Reihenfolge der Module in dem Abschnitt, oder führen Sie die Anwendung im klassischen Modus aus.
Im integrierten Modus werden Threading- und Warteschlangeneinstellungen ignoriert.
Im integrierten Modus verarbeitet ASP.NET (nicht IIS) Anforderungen in Threads und verwendet nicht die im klassischen Modus verwendete Threading- oder Warteschlangensemantik. Aufgrund dieses Unterschieds können Anwendungen im integrierten Modus unterschiedliche Durchsatzwerte oder ein unterschiedliches Verhalten unter Last aufweisen als bei Ausführung im klassischen Modus.
Wenn bei Verwendung des integrierten Modus ein Konfigurationsdateifehler auftritt, wird die Fehlermeldung nicht von ASP.NET, sondern von IIS generiert.
Für Anwendungen, die im integrierten Modus ausgeführt werden, werden Anwendungskonfigurationsdateien jetzt von IIS gelesen. Daher generiert nicht ASP.NET, sondern IIS eine Fehlermeldung, wenn in der Datei „Web.config“ falsch formatierter XML-Code gefunden wird oder die Datei Konfigurationsfehler enthält.
Da IIS und ASP.NET Fehler in unterschiedlichen Formaten schreiben, unterscheidet sich das Format der Fehlermeldung abhängig davon, ob die Anwendung im integrierten Modus oder im klassischen Modus ausgeführt wird. Nachfolgend sehen Sie ein Beispiel für einen Typ eines Konfigurationsdateifehlers, der von IIS generiert wird: „Interner Serverfehler: Konfigurationsfehler: Die Konfigurationsdatei enthält keinen ordnungsgemäß konfigurierten XML-Code.“
Im integrierten Modus müssen ASP.NET-Anwendungen Pipelineereignisse während des Init-Aufrufs eines Moduls abonnieren.
ASP.NET-Anwendungen, die die HTTP-Pipeline von ASP.NET verwenden, können Anwendungsereignisse außerhalb der Pipeline abonnieren. ASP.NET-Anwendungen, die die Pipeline für den integrierten Modus von IIS verwenden, müssen jetzt allerdings immer Ereignisse während der Init()-Methode des Moduls abonnieren. Das folgende Beispiel zeigt, wie ein Ereignisabonnement in „Init“ implementiert wird:
Public void Init(httpApplication context)
{
Context.AuthenticateRequest += new EventHandler(this.AuthenticateUser);
}
Weitere Informationen zum Erstellen von IIS-Modulen finden Sie im Artikel Entwickeln eines Moduls mit .NET.
Weitere Ressourcen
Weitere Informationen zum Upgraden auf IIS 7.0 und höhere Versionen unter Windows Vista finden Sie hier im Artikel zur IIS 7.0-Anwendungskompatibilität unter Windows Vista.