Freigeben über

ASP.NET 2.0: Breaking Changes in IIS 7.0

von Mike Volodarsky

Einführung

ASP.NET 2.0-Anwendungen in IIS 7.0 und höheren Versionen werden standardmäßig mit dem integrierten Modus von ASP.NET gehostet. Dieser neue Modus ermöglicht eine Vielzahl spannender Szenarien, einschließlich der Verwendung praktischer ASP.NET-Features wie der Formularauthentifizierung für Ihre gesamte Website und der Entwicklung neuer ASP.NET-Module, um unter anderem Funktionen wie das Umschreiben von URLs sowie Autorisierungs- und Protokollierungsfunktionen auf IIS-Ebene zu nutzen. Weitere Informationen zur ASP.NET-Integration in IIS finden Sie unter ASP.NET-Integration in IIS 7.

Wir haben nicht nur ASP.NET-Anwendungen in IIS 7.0 und höheren Versionen leistungsfähiger gemacht, sondern auch sorgfältig darauf geachtet, dass bereits vorhandene ASP.NET-Anwendungen weiterhin funktionieren, wenn sie zu dieser neuen Plattform migriert werden. Dies war eine große Herausforderung für uns, da wir die gesamte zugrunde liegende Engine von ASP.NET umgestaltet haben. Letztendlich haben wir diese Herausforderung aber bestens gemeistert. Daher sollten die meisten ASP.NET-Anwendungen unverändert funktionieren.

In diesem Artikel werden die Verhaltensänderungen aufgeführt, die sich durch die Bereitstellung Ihrer ASP.NET-Anwendungen in IIS 7.0 und höheren Versionen unter Windows Vista SP1 und Windows Server 2008 ergeben können. Wenn nichts anderes angegeben ist, treten diese Breaking Changes nur bei Verwendung des standardmäßigen integrierten Modus von ASP.NET auf.

Verwenden des klassischen ASP.NET-Modus

IIS 7.0 und höhere Versionen bieten auch die Möglichkeit, ASP.NET-Anwendungen mit dem älteren klassischen Integrationsmodus von ASP.NET auszuführen. Dies funktioniert auf die gleiche Weise wie bei ASP.NET in früheren Versionen von IIS. Es wird jedoch dringend empfohlen, nach Möglichkeit eine Problemumgehung zu verwenden, um Ihre Anwendung für die Verwendung des integrierten Modus anzupassen. Durch die Umstellung auf den klassischen Modus kann Ihre Anwendung nicht von ASP.NET-Verbesserungen profitieren, die durch den integrierten Modus ermöglicht werden, da für die Nutzung zukünftiger Features von Microsoft und Drittanbietern möglicherweise der integrierte Modus erforderlich ist. Der klassische Modus sollte nur verwendet werden, wenn Sie die angegebene Problemumgehung nicht anwenden können. Weitere Informationen zur Umstellung auf den klassischen Modus finden Sie unter Ändern des ASP.NET-Modus für eine Anwendung.

Im Anschluss werden einige der Breaking Changes im Detail erläutert. Falls verfügbar, stehen Links zu Blogbeiträgen zur Verfügung, die zusätzliche Details und Problemumgehungsinformationen enthalten. Sollten Sie weitere Informationen zu einem bestimmten Problem benötigen, können Sie eine Frage in den IIS.NET-Foren veröffentlichen.

Aktuelle Änderungen

Migrationsfehler

Diese Fehler treten aufgrund von Änderungen bei der Anwendung von ASP.NET-Konfigurationen im integrierten Modus auf. IIS erkennt diese Konfigurationen automatisch und gibt einen Fehler aus, in dem Sie gebeten werden, Ihre Anwendung zu migrieren oder auf den klassischen Modus umzustellen, falls die Migration nicht in Frage kommt (siehe Breaking Change 3 weiter unten).

1. ASP.NET-Anwendungen müssen migriert werden, wenn eine Konfiguration in <httpModules> oder <httpHandlers> angegeben wird.

Sie erhalten einen internen Serverfehler mit dem Fehlercode 500. Hierbei kann es sich um den HTTP-Fehler 500.22 oder um den HTTP-Fehler 500.23 handeln: Es wurde eine ASP.NET-Einstellung erkannt, die im integrierten verwalteten Pipelinemodus nicht gültig ist. Dieser Fehler tritt auf, da ASP.NET-Module und -Handler im integrierten Modus in den IIS-Konfigurationsabschnitten <handlers> und <modules> angegeben werden müssen.

Problemumgehung

A. Sie müssen die Anwendungskonfiguration migrieren, damit sie im integrierten Modus ordnungsgemäß funktioniert. Die Anwendungskonfiguration kann mithilfe von AppCmd migriert werden:

> %windir%\system32\inetsrv\Appcmd migrate config "<ApplicationPath>"

B. Sie können die Migration manuell durchführen, indem Sie die benutzerdefinierten Einträge in der Konfiguration <system.web>/<httpModules> und <system.web>/<httpHandlers> manuell in die Konfigurationsabschnitte <system.webServer>/<handlers> und <system.webServer>/<modules> verschieben und entweder die Konfiguration <httpHandlers> und <httpModules> entfernen ODER Folgendes zur Datei „web.config“ Ihrer Anwendung hinzufügen:

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

2. ASP.NET-Anwendungen erzeugen eine Warnung, wenn die Anwendung durch Angeben von <identity impersonate="true"> in der Konfiguration Identitätswechsel bei Anforderungen ermöglicht.

Sie erhalten einen internen Serverfehler mit dem Fehlercode 500. Hier sehen Sie den HTTP-Fehler 500.24: Es wurde eine ASP.NET-Einstellung erkannt, die im integrierten verwalteten Pipelinemodus nicht gültig ist. Dieser Fehler tritt auf, da im integrierten Modus von ASP.NET die Anforderungsidentität in den Pipelinephasen „BeginRequest“ und „AuthenticateRequest“ nicht gewechselt werden kann.

Problemumgehung

A. Wenn Ihre Anwendung nicht darauf angewiesen ist, in den Phasen „BeginRequest“ und „AuthenticateRequest“ (den einzigen Phasen, in denen der Identitätswechsel im integrierten Modus nicht möglich ist) die Identität des anfordernden Benutzers anzunehmen, ignorieren Sie diesen Fehler, indem Sie der Datei „web.config“ Ihrer Anwendung Folgendes hinzufügen:

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

B. Wenn Ihre Anwendung auf Identitätswechsel in „BeginRequest“ und „AuthenticateRequest“ angewiesen ist oder Sie nicht sicher sind, wechseln Sie in den klassischen Modus.

3. Sie erhalten einen Konfigurationsfehler, wenn Ihre Anwendungskonfiguration einen verschlüsselten Abschnitt vom Typ <identity> enthält.

Sie erhalten einen internen Serverfehler mit dem Fehlercode 500. Hier sehen Sie den HTTP-Fehler 500.19: Auf die angeforderte Seite kann nicht zugegriffen werden, da die zugehörigen Konfigurationsdaten für die Seite ungültig sind. In den ausführlichen Fehlerinformationen ist angegeben, dass die Verschlüsselung des Konfigurationsabschnitts nicht unterstützt wird. Dieser Fehler tritt auf, da IIS versucht, den Abschnitt <identity> zu überprüfen und die Verschlüsselung auf Abschnittsebene nicht lesen kann.

Problemumgehung

A. Wenn Ihre Anwendung nicht das Problem mit dem Identitätswechsel für Anforderungen aus dem Breaking Change 2 hat, migrieren Sie Ihre Anwendungskonfiguration mithilfe von AppCmd, wie im Breaking Change 1 beschrieben:

> %windir%\system32\inetsrv\Appcmd migrate config "<ApplicationPath>"

Dadurch wird sichergestellt, dass die restliche Anwendungskonfiguration migriert wird, und der Datei „web.config“ wird automatisch Folgendes hinzugefügt, um den Abschnitt <Identity> zu ignorieren:

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

B. Falls Ihre Anwendung von dem Problem mit dem Identitätswechsel für Anforderungen betroffen ist, wechseln Sie in den klassischen Modus.

Authentifizierung, Autorisierung und Identitätswechsel

Im integrierten Modus wurden IIS- und ASP.NET-Authentifizierungsphasen vereinheitlicht. Daher sind die Ergebnisse der IIS-Authentifizierung erst in der PostAuthenticateRequest-Phase verfügbar, wenn sowohl die ASP.NET- als auch die IIS-Authentifizierungsmethoden abgeschlossen sind. Dadurch ergeben sich folgende Änderungen:

4. Anwendungen können nicht gleichzeitig die Formularauthentifizierung (FormsAuthentication) die Windows-Authentifizierung (WindowsAuthentication) nutzen.

Anders als im klassischen Modus ist es nicht möglich, die Formularauthentifizierung in ASP.NET zu verwenden und weiterhin eine Benutzerauthentifizierung mit einer IIS-Authentifizierungsmethode wie der Windows-Authentifizierung oder der Standardauthentifizierung erforderlich zu machen. Wenn die Formularauthentifizierung aktiviert ist, müssen alle anderen IIS-Authentifizierungsmethoden deaktiviert werden (mit Ausnahme der anonymen Authentifizierung).
Darüber hinaus gelten bei Verwendung der Formularauthentifizierung folgende Änderungen:

  • Die Servervariable „LOGON_USER“ wird auf den Namen des Benutzers der Formularauthentifizierung festgelegt.

  • Es ist nicht möglich, die Identität des authentifizierten Clients anzunehmen. Um die Identität des authentifizierten Clients zu anzunehmen, muss anstelle der Formularauthentifizierung eine Authentifizierungsmethode verwendet werden, die einen Windows-Benutzer erzeugt.

Problemumgehung

A. Ändern Sie Ihre Anwendung so, dass das im folgenden Artikel erläuterte Muster verwendet: IIS 7.0: Zweistufige Authentifizierung mit Formularauthentifizierung und Windows-Authentifizierung.

5. Die Windows-Authentifizierung wird standardmäßig im Kernel durchgeführt, was dazu führen kann, dass für HTTP-Clients, die Anmeldeinformationen in der ursprünglichen Anforderung senden, ein Fehler auftritt.

In IIS 7.0 und höheren Versionen ist die Kernelmodusauthentifizierung standardmäßig aktiviert. Dadurch wird die Leistung der Windows-Authentifizierung verbessert und die Bereitstellung des Kerberos-Authentifizierungsprotokolls vereinfacht. Es kann jedoch dazu führen, dass bei einigen Clients, die Windows-Anmeldeinformationen in der ursprünglichen Anforderung senden, aufgrund einer Entwurfsbeschränkung bei der Kernelmodusauthentifizierung ein Fehler auftritt. Normale Browserclients sind davon nicht betroffen, da sie die ursprüngliche Anforderung immer anonym senden.

Hinweis

Dieser Breaking Change betrifft sowohl den klassischen als auch den integrierten Modus.

Problemumgehung

A. Deaktivieren Sie die Kernelmodusauthentifizierung, indem Sie den „userKernelMode“ im Abschnitt „system.webServer/security/authentication/windowsAuthentication“ auf „false“ festlegen. Hierzu kann auch AppCmd verwendet werden:

> %windir%\system32\inetsrv\appcmd set config /section:windowsAuthentication /useKernelMode:false

6. Die Passport-Authentifizierung wird nicht unterstützt.

Sie erhalten einen ASP.NET-Serverfehler mit dem Fehlercode 500: Das PassportManager-Objekt konnte nicht initialisiert werden. Stellen Sie sicher, dass Microsoft Passport ordnungsgemäß auf dem Server installiert ist. Die Passport-Authentifizierung wird unter Windows Vista und Windows Server 2008 nicht mehr unterstützt.

Hinweis

Dieser Breaking Change betrifft sowohl den klassischen als auch den integrierten Modus.

7. Wenn in einem Modul vor „PostAuthenticateRequest“ auf „HttpRequest.LogonUserIdentity“ zugegriffen wird, wird eine Ausnahme vom Typ „InvalidOperationException“ ausgelöst.

Sie erhalten einen ASP.NET-Serverfehler mit dem Fehlercode 500: Diese Methode kann nur nach dem Authentifizierungsereignis aufgerufen werden. Wenn vor „PostAuthenticateRequest“ auf „HttpRequest.LogonUserIdentity“ zugegriffen wird, wird eine Ausnahme vom Typ „InvalidOperationException“ ausgelöst, da der Wert dieser Eigenschaft erst nach der Authentifizierung des Clients bekannt ist.

Problemumgehung

A. Ändern Sie den Code so, dass frühestens in der PostAuthenticateRequest-Phase auf „HttpRequest.LogonUserIdentity“ zugegriffen wird.

8. In einem Modul wird die Annahme der Clientidentität in den Phasen „BeginRequest“ und „AuthenticateRequest“ nicht angewendet.

Der authentifizierte Benutzer ist erst in der PostAuthenticateRequest-Phase bekannt. Daher nimmt ASP.NET für ASP.NET-Module, die in der BeginRequest- oder AuthenticateRequest-Phase ausgeführt werden, nicht die Identität des authentifizierten Benutzers an. Dies kann sich auf Ihre Anwendung auswirken, wenn Sie über benutzerdefinierte Module verfügen, die in diesen Phasen die Identität des Clients annehmen müssen, um den Zugriff auf Ressourcen zu überprüfen oder auf Ressourcen zuzugreifen.

Problemumgehung

A. Ändern Sie Ihre Anwendung so, dass in den Phasen „BeginRequest“ und „AuthenticateRequest“ keine Annahme der Clientidentität erforderlich ist.

9. Wenn in „global.asax“ eine DefaultAuthentication_OnAuthenticate-Methode definiert wird, wird eine Ausnahme vom Typ „PlatformNotSupportedException“ ausgelöst.

Sie erhalten einen ASP.NET Serverfehler mit dem Fehlercode 500: Die DefaultAuthentication.Authenticate-Methode wird vom integrierten IIS-Pipelinemodus nicht unterstützt. Im integrierten Modus ist das DefaultAuthenticationModule.Authenticate-Ereignis nicht implementiert und wird daher auch nicht mehr ausgelöst. Im klassischen Modus wird dieses Ereignis ausgelöst, wenn keine Authentifizierung erfolgt ist.

Problemumgehung

A. Ändern Sie die Anwendung so, dass sie nicht auf das DefaultAuthentication_OnAuthenticate-Ereignis angewiesen ist. Schreiben Sie stattdessen ein Modul vom Typ „IHttpModule“, das untersucht, ob „HttpContext.User“ NULL ist, um zu bestimmen, ob ein authentifizierter Benutzer vorhanden ist.

10. Anwendungen, die „WindowsAuthentication_OnAuthenticate“ in „global.asax“ implementieren, werden nicht benachrichtigt, wenn die Anforderung anonym ist.

Wenn Sie in „global.asax“ die WindowsAuthentication_OnAuthenticate-Methode definieren, wird sie für anonyme Anforderungen nicht aufgerufen. Das liegt daran, dass die anonyme Authentifizierung erst erfolgt, nachdem das WindowsAuthentication-Modul das OnAuthenticate-Ereignis auslösen kann.

Problemumgehung

A. Ändern Sie Ihre Anwendung so, dass die WindowsAuthentication_OnAuthenticate-Methode nicht verwendet wird. Implementieren Sie stattdessen ein Modul vom Typ „IHttpModule“, das in „PostAuthenticateRequest“ ausgeführt wird und „HttpContext.User“ überprüft.

Anforderungslimits und URL-Verarbeitung

Die folgenden Änderungen ergeben sich durch zusätzliche Einschränkungen bei der Verarbeitung eingehender Anforderungen und der zugehörigen URLs durch IIS:

11. Anforderungs-URLs mit nicht codierten Pluszeichen (+) im Pfad (nicht in der Abfragezeichenfolge) werden standardmäßig abgelehnt.

Sie erhalten einen HTTP-Fehler vom Typ „404.11 – Nicht gefunden“: Das Anforderungsfiltermodul ist so konfiguriert, dass Anforderungen mit doppelter Escapesequenz abgelehnt werden. Dieser Fehler tritt auf, weil IIS standardmäßig so konfiguriert ist, dass URLs mit doppelter Codierung abgelehnt werden, da dies häufig auf einen Kanonisierungsangriff hindeutet.

Problemumgehung

A. Bei Anwendungen, die auf die Verwendung des Pluszeichens (+) im URL-Pfad angewiesen sind, kann diese Überprüfung deaktiviert werden. Legen Sie hierzu in der Datei „web.config“ der Anwendung im Konfigurationsabschnitt system.webServer/security/requestFiltering das Attribut allowDoubleEscaping fest. Dadurch ist Ihre Anwendung jedoch unter Umständen anfälliger für böswillige URLs:

<system.webServer>
    <security>
        <requestFiltering allowDoubleEscaping="true" />
    </security>
</system.webServer>

12. Anforderungen mit Abfragezeichenfolgen, die größer als 2.048 Bytes sind, werden standardmäßig abgelehnt.

Sie erhalten einen HTTP-Fehler vom Typ „404.15 – Nicht gefunden“: Das Anforderungsfiltermodul ist so konfiguriert, dass Anforderungen mit zu langer Abfragezeichenfolge abgelehnt werden. IIS ist standardmäßig so konfiguriert, dass Abfragezeichenfolgen mit einer Größe von mehr als 2.048 Bytes abgelehnt werden. Dies kann sich auf Ihre Anwendung auswirken, wenn sie große Abfragezeichenfolgen oder cookielose ASP.NET-Features wie etwa die Formularauthentifizierung verwendet, die das für die Abfragezeichenfolgengröße konfigurierte Limit insgesamt überschreiten.

Hinweis

Dieser Breaking Change betrifft sowohl den klassischen als auch den integrierten Modus.

Problemumgehung

A. Erhöhen Sie die maximal zulässige Größe der Abfragezeichenfolge, indem Sie in der Datei „web.config“ der Anwendung im Konfigurationsabschnitt system.webServer/security/requestFiltering das Attribut maxQueryString für das Element requestLimits festlegen:

<system.webServer>
    <security>
    <requestFiltering>
        <requestLimits maxQueryString="NEW_VALUE_IN_BYTES" />
    </requestFiltering>
    </security>
</system.webServer>

Änderungen bei der Verarbeitung von Antwortheadern

Diese Änderungen wirken sich darauf aus, wie Antwortheader von der Anwendung generiert werden.

13. Neue Zeilen in Antwortheadern werden von IIS immer abgelehnt (auch wenn „enableHeaderChecking“ von ASP.NET auf „false“ festgelegt ist).

Falls Ihre Anwendung Header mit Zeilenumbrüchen (beliebige Kombination von „\r“ oder „\n“) schreibt, erhalten Sie einen ASP.NET-Serverfehler mit dem Fehlercode 500: Der Wert liegt nicht im erwarteten Bereich. IIS lehnt alle Versuche ab, Antwortheader mit Zeilenumbrüchen zu erstellen – auch wenn das enableHeaderChecking-Verhalten von ASP.NET deaktiviert ist. Dies dient zur Vermeidung von Header-Splitting-Angriffen.

Hinweis

Dieser Breaking Change betrifft sowohl den klassischen als auch den integrierten Modus.

14. Wenn die Antwort leer ist, wird der Content-Type-Header nicht unterdrückt.

Wenn die Anwendung einen Content-Type-Header festlegt, bleibt er auch dann vorhanden, wenn die Antwort gelöscht wird. Bei Anforderungen für ASP.NET-Inhaltstypen ist in Antworten in der Regel „Content-Type: text/html“ enthalten, es sei denn, dies wird von der Anwendung außer Kraft gesetzt.

Problemumgehung

A. Dies sollte zwar keine unterbrechende Wirkung haben, Sie können den Content-Type-Header jedoch entfernen, indem Sie die Eigenschaft HttpResponse.ContentType explizit auf null festlegen, wenn sie die Antwort löschen.

15. Wenn die Antwortheader mithilfe von „HttpResponse.ClearHeaders“ gelöscht werden, werden keine ASP.NET-Standardheader generiert, was dazu führen kann, dass der Header „Cache-Control: private“ fehlt, der die Zwischenspeicherung der Antwort auf dem Client verhindert.

Anders als im klassischen Modus werden ASP.NET-Standardantwortheader von „HttpResponse.ClearHeaders“ nicht erneut generiert. Das gilt auch für „Content-Type: text/html“ und für „Cache-Control: private“. Das liegt daran, dass ASP.NET-Module diese API für Anforderungen an einen beliebigen Ressourcentyp aufrufen können und daher die Generierung ASP.NET-spezifischer Header nicht sinnvoll ist. Die Abwesenheit des Headers „Cache-Control“ kann dazu führen, dass einige nachgeschaltete Netzwerkgeräte die Antwort zwischenspeichern.

Problemumgehung

A. Ändern Sie die Anwendung so, dass der Header „Cache-Control: private“ beim Löschen der Antwort manuell generiert wird, wenn die Zwischenspeicherung auf nachgeschalteten Netzwerkgeräten unterbunden werden soll.

Änderungen an der Verarbeitung von Anwendungs- und Modulereignissen

Diese Änderungen wirken sich auf die Verarbeitung von Anwendungs- und Modulereignissen aus.

16. Es ist nicht möglich, über die Eigenschaft „HttpContext.Current“ in „Application_Start“ in „global.asax“ auf die Anforderung zuzugreifen.

Wenn Ihre Anwendung im Rahmen der Anwendungsinitialisierung auf den aktuellen Anforderungskontext in der Methode „Application_Start“ in „global.asax“ zugreift, erhalten Sie einen ASP.NET-Serverfehler mit dem Fehlercode 500: Die Anforderung ist in diesem Kontext nicht verfügbar. Dieser Fehler tritt auf, da die ASP.NET-Anwendungsinitialisierung von der Anforderung entkoppelt wurde, die sie auslöst. Im klassischen Modus konnte durch Zugreifen auf die Eigenschaft „HttpContext.Current“ indirekt auf den Anforderungskontext zugegriffen werden. Im integrierten Modus stellt dieser Kontext nicht mehr die eigentliche Anforderung dar. Daher führt der Versuch, auf die Anforderungs- und Antwortobjekte zuzugreifen, zu einer Ausnahme.

Problemumgehung

A. Ausführliche Informationen zu diesem Problem sowie verfügbare Problemumgehungen finden Sie unter Integrierter Modus von IIS7: Ausnahme „Die Anforderung ist in diesem Kontext nicht verfügbar.“ in „Application_Start“.

17. Die Ausführungsreihenfolge der Modulereignishandler unterscheidet sich ggf. von der Reihenfolge im klassischen Modus.

Folgende Unterschiede sind vorhanden:

  • Für jedes Ereignis werden Ereignishandler für die einzelnen Module in der Reihenfolge ausgeführt, in der Module im Konfigurationsabschnitt <modules> konfiguriert sind. Ereignishandler vom Typ „global.asax“ werden zuletzt ausgeführt.

  • Module, die sich für die Ereignisse „PreSendRequestHeaders“ und „PreSendRequestContent“ registrieren, werden in umgekehrter Reihenfolge der Anzeige im Konfigurationsabschnitt <modules> benachrichtigt.

  • Für jedes Ereignis werden synchrone Ereignishandler für die einzelnen Module vor asynchronen Handlern ausgeführt. Ansonsten werden Ereignishandler in der Reihenfolge ausgeführt, in der sie registriert sind.

Anwendungen mit mehreren Modulen, die für die Ausführung in einem dieser Ereignisse konfiguriert sind, sind ggf. von diesen Änderungen betroffen, wenn sie gemeinsam von der Ereignisreihenfolge abhängig sind. Dies ist bei den meisten Anwendungen wahrscheinlich nicht der Fall. Die Ausführungsreihenfolge von Modulen kann aus einem Ablaufverfolgungsprotokoll für Anforderungsfehler abgerufen werden.

Problemumgehung:

A. Ändern Sie die Reihenfolge der Module, bei denen ein Problem mit der Reihenfolge auftritt, im Konfigurationsabschnitt system.webServer/modules.

18. ASP.NET-Module in frühen Anforderungsverarbeitungsphasen werden Anforderungen präsentiert, die ggf. bereits von IIS abgelehnt wurden, bevor sie ASP.NET erreicht haben. Dazu gehört unter anderem, dass Modulen, die in „BeginRequest“ ausgeführt werden, anonyme Anforderungen für Ressourcen präsentiert werden, die eine Authentifizierung erfordern.

ASP.NET-Module können in beliebigen Pipelinephasen ausgeführt werden, die für native IIS-Module verfügbar sind. Dies kann dazu führen, dass Anforderungen, die ggf. zuvor in der Authentifizierungsphase abgelehnt wurden (z. B. anonyme Anforderungen für Ressourcen, die eine Authentifizierung erfordern), oder Anforderungen, die in anderen Phasen vor dem Erreichen von ASP.NET abgelehnt wurden, ASP.NET-Module ausführen. Dieses Verhalten ist beabsichtigt, damit ASP.NET-Module IIS in allen Phasen der Anforderungsverarbeitung erweitern können.

Problemumgehung

A. Ändern Sie den Anwendungscode, um anwendungsspezifische Probleme zu vermeiden, die durch Anforderungen entstehen, die ggf. später im Rahmen der Anforderungsverarbeitung abgelehnt werden. Hierzu müssen unter Umständen Module geändert werden, um Pipelineereignisse zu abonnieren, die später während der Anforderungsverarbeitung ausgelöst werden.

Andere Anwendungsänderungen

Andere Änderungen am Verhalten von ASP.NET-Anwendungen und APIs.

19. „DefaultHttpHandler“ wird nicht unterstützt, sodass Anwendungen, die auf Unterklassen von „DefaultHttpHandler“ angewiesen sind, keine Anforderungen verarbeiten können.

Wenn Ihre Anwendung „DefaultHttpHandler“ oder davon abgeleitete Handler verwendet, funktioniert sie nicht ordnungsgemäß. Im integrierten Modus können von „DefaultHttpHandler“ abgeleitete Handler die Anforderung nicht zur Verarbeitung an IIS zurückgeben und verarbeiten die angeforderte Ressource stattdessen als statische Datei. Im integrierten Modus können ASP.NET-Module für alle Anforderungen ausgeführt werden, ohne das dafür „DefaultHttpHandler“ verwendet werden muss.

Problemumgehung

A. Ändern Sie Ihre Anwendung so, dass sie für die Verarbeitung aller Anforderungen Module verwendet, anstatt die Platzhalterzuordnung zu verwenden, um ASP.NET allen Anforderungen zuzuordnen und dann von DefaultHttpHandler abgeleitete Handler zu verwenden, um die Anforderung an IIS zurückzugeben.

20. Es ist möglich, in die Antwort zu schreiben, nachdem eine Ausnahme aufgetreten ist.

Im integrierten Modus ist es möglich, einen Schreibvorgang auszuführen und eine zusätzliche Antwort anzuzeigen, die geschrieben wurde, nachdem eine Ausnahme aufgetreten ist (in der Regel in Modulen, die die Ereignisse „LogRequest“ und „EndRequest“ abonnieren). 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.

21. Es ist nicht möglich, die ClearError-API zu verwenden, um zu verhindern, dass eine Ausnahme in die Antwort geschrieben wird, wenn die Ausnahme in einer vorherigen Pipelinephase aufgetreten ist.

Problemumgehung

A. Ändern Sie die Anwendung so, dass „Server.ClearError“ über den Application_OnError-Ereignishandler aufgerufen wird. Dieser wird immer dann ausgelöst, wenn eine Ausnahme ausgelöst wird.

22. „HttpResponse.AppendToLog“ stellt der URL nicht automatisch die Abfragezeichenfolge voran.

Wenn Sie „HttpResponse.AppendToLog“ verwenden, um eine benutzerdefinierte Zeichenfolge an die URL anzufügen, die in der Anforderungsprotokolldatei protokolliert ist, müssen Sie die Abfragezeichenfolge manuell der Zeichenfolge voranstellen, die Sie an diese API übergeben. Dies kann dazu führen, dass vorhandener Code nicht mehr über die Abfragezeichenfolge aus der protokollierten URL verfügt, wenn diese API verwendet wird.

Problemumgehung

A. Ändern Sie Ihre Anwendung so, dass der an „HttpResponse.AppendToLog“ übergebenen Zeichenfolge manuell „HttpResponse.QueryString.ToString()“ vorangestellt wird.

Weitere Änderungen

Sonstige Änderungen

23. ASP.NET-Threadingeinstellungen werden im integrierten Modus nicht zum Steuern der Parallelität von Anforderungen verwendet.

Die Einstellungen minFreeThreads und minLocalRequestFreeThreads im Konfigurationsabschnitt system.web/httpRuntime sowie die Einstellung maxWorkerThreads im Konfigurationsabschnitt processModel steuern nicht mehr den von ASP.NET verwendeten Threadingmechanismus. Stattdessen nutzt ASP.NET den IIS-Threadpool und ermöglicht es Ihnen, die maximale Anzahl gleichzeitig ausgeführter Anforderungen zu steuern, indem Sie den DWORD-Wert MaxConcurrentRequestsPerCPU im Schlüssel „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ASP.NET\2.0.50727.0“ festlegen. (Der Standardwert ist „12“.) Diese Einstellung ist global und kann nicht für einzelne Anwendungspools oder Anwendungen geändert werden.

Problemumgehung

A. Legen Sie die Einstellung „MaxConcurrentRequestsPerCPU“ fest, um die Parallelität Ihrer Anwendung zu steuern.

24. Im integrierten Modus werden keine ASP.NET-Anwendungswarteschlangen verwendet. Daher hat der Leistungsindikator „ASP.NET-Anwendungen\Anforderungen in der Anwendungswarteschlange“ immer den Wert „0“.

ASP.NET verwendet im integrierten Modus keine Anwendungswarteschlangen.

25. Ab IIS 7.0 werden ASP.NET-Anwendungen immer neu gestartet, wenn Änderungen an der Stammdatei „web.config“ der Anwendung vorgenommen werden. Daher haben die Attribute „waitChangeNotification“ und „maxWaitChangeNotification“ keine Wirkung.

IIS 7.0 und höhere Versionen überwachen auch Änderungen an den Dateien vom Typ „web.config“ und sorgen dafür, dass die entsprechende ASP.NET-Anwendung neu gestartet wird. Die Änderungsbenachrichtigungseinstellungen von ASP.NET, zu denen auch die Attribute waitChangeNotification und maxWaitChangeNotification in den Konfigurationsabschnitten vom Typ „system.web/httpRuntime“ zählen, werden hierbei nicht berücksichtigt.

Wir hoffen, dass Ihr Umstieg auf den integrierten Modus in IIS 7.0 und höheren Versionen so reibungslos wie möglich verläuft, damit Sie in Ihren Anwendungen sofort von den IIS-Features und der Leistungsfähigkeit der ASP.NET-Integration profitieren können.

Veröffentlichen Sie gerne einen Beitrag in den IIS.NET-Foren, falls Sie Probleme mit einem dieser Breaking Changes haben oder eine andere Verhaltensänderung in Ihrer Anwendung feststellen, die hier nicht aufgeführt ist.