Was ist der Unterschied zwischen dem "klassischen" und dem "integrierten" Pipeline-Modus in IIS7?

Ich habe gestern Abend eine ASP.NET MVC-Anwendung bereitgestellt und festgestellt, dass die Bereitstellung mit IIS7 im integrierten Modus weniger Arbeit erfordert. Meine Frage ist, was ist der Unterschied? Und was bedeutet es, das eine oder andere zu verwenden?

Der klassische Modus (der einzige Modus in IIS6 und darunter) ist ein Modus, in dem IIS nur mit ISAPI-Erweiterungen und ISAPI-Filtern direkt funktioniert. In diesem Modus ist ASP.NET nur eine ISAPI-Erweiterung (aspnet_isapi.dll) und ein ISAPI-Filter (aspnet_filter.dll). IIS behandelt ASP.NET lediglich als ein in ISAPI implementiertes externes Plugin und arbeitet damit wie eine Black Box (und nur dann, wenn die Anforderung an ASP.NET gesendet werden muss). In diesem Modus unterscheidet sich ASP.NET nicht wesentlich von PHP oder anderen Technologien für IIS.

Der integrierte Modus ist dagegen ein neuer Modus in IIS7, in dem die IIS-Pipeline eng integriert ist (dh genau so ist) wie die ASP.NET-Anforderungspipeline. ASP.NET kann jede gewünschte Anforderung anzeigen und die Dinge auf dem Weg bearbeiten. ASP.NET wird nicht mehr als externes Plugin behandelt. Es ist vollständig gemischt und in IIS integriert. In diesem Modus haben ASP.NETs im HttpModuleGrunde fast so viel Leistung wie ein ISAPI-Filter, und ASP.NETs HttpHandlerkönnen nahezu gleichwertig sein wie eine ISAPI-Erweiterung. In diesem Modus ist ASP.NET grundsätzlich Teil von IIS.

Integrierter Anwendungspoolmodus

Wenn sich ein Anwendungspool im integrierten Modus befindet, können Sie die integrierte Anforderungsverarbeitungsarchitektur von IIS und ASP.NET nutzen. Wenn ein Arbeitsprozess in einem Anwendungspool eine Anforderung empfängt, durchläuft die Anforderung eine geordnete Liste von Ereignissen. Jedes Ereignis ruft die erforderlichen nativen und verwalteten Module auf, um Teile der Anforderung zu verarbeiten und die Antwort zu generieren.

Das Ausführen von Anwendungspools im integrierten Modus bietet mehrere Vorteile. Zunächst werden die Anforderungsverarbeitungsmodelle von IIS und ASP.NET in ein einheitliches Prozessmodell integriert. Dieses Modell eliminiert Schritte, die zuvor in IIS und ASP.NET dupliziert wurden, z. B. die Authentifizierung. Darüber hinaus ermöglicht der integrierte Modus die Verfügbarkeit verwalteter Funktionen für alle Inhaltstypen.

Klassischer Anwendungspoolmodus

Wenn sich ein Anwendungspool im klassischen Modus befindet, verarbeitet IIS 7.0 Anforderungen wie im Isolationsmodus für IIS 6.0-Arbeitsprozesse. ASP.NET-Anforderungen durchlaufen zunächst native Verarbeitungsschritte in IIS und werden dann zur Verarbeitung von verwaltetem Code zur verwalteten Laufzeit an Aspnet_isapi.dll weitergeleitet. Schließlich wird die Anforderung über IIS zurückgeleitet, um die Antwort zu senden.

Diese Trennung der IIS- und ASP.NET-Anforderungsverarbeitungsmodelle führt zu einer Verdoppelung einiger Verarbeitungsschritte, z. B. Authentifizierung und Autorisierung. Darüber hinaus sind verwaltete Codefunktionen wie die Formularauthentifizierung nur für ASP.NET-Anwendungen oder Anwendungen verfügbar, für die Sie alle Anforderungen, die von aspnet_isapi.dll verarbeitet werden sollen, per Skript zugeordnet haben.

Stellen Sie sicher, dass Sie Ihre vorhandenen Anwendungen im integrierten Modus auf Kompatibilität testen, bevor Sie eine Produktionsumgebung auf IIS 7.0 aktualisieren und Anwendungen Anwendungspools im integrierten Modus zuweisen. Sie sollten einem Anwendungspool im klassischen Modus nur dann eine Anwendung hinzufügen, wenn die Anwendung im integrierten Modus nicht funktioniert. Beispielsweise kann Ihre Anwendung auf ein Authentifizierungstoken angewiesen sein, das von IIS an die verwaltete Laufzeit übergeben wird, und aufgrund der neuen Architektur in IIS 7.0 bricht der Prozess Ihre Anwendung.

Entnommen aus: Was ist der Unterschied zwischen DefaultAppPool und Classic .NET AppPool in IIS7?

Originalquelle: Einführung in die IIS-Architektur

IIS 6.0 und frühere Versionen:

ASP.NET wurde über eine ISAPI-Erweiterung, eine C-API (C Programming Language Based API) in IIS integriert und stellte ein eigenes Anwendungs- und Anforderungsverarbeitungsmodell bereit.

Dadurch wurden zwei separate Server-Pipelines (Anforderungs- / Antwort-Pipelines) verfügbar gemacht, eine für native ISAPI-Filter und Erweiterungskomponenten und eine für verwaltete Anwendungskomponenten. ASP.NET-Komponenten werden vollständig innerhalb der ASP.NET ISAPI-Erweiterungsblase UND NUR für Anforderungen ausgeführt, die ASP.NET in der IIS-Skriptzuordnungskonfiguration zugeordnet sind.

Anforderungen an Nicht-ASP.NET-Inhaltstypen: - Bilder, Textdateien, HTML-Seiten und skriptlose ASP-Seiten wurden von IIS oder anderen ISAPI-Erweiterungen verarbeitet und waren für ASP.NET NICHT sichtbar.

Die Hauptbeschränkung dieses Modells bestand darin, dass Dienste, die von ASP.NET-Modulen und benutzerdefiniertem ASP.NET-Anwendungscode bereitgestellt wurden, NICHT für Nicht-ASP.NET-Anforderungen verfügbar waren

Was ist eine SCRIPT-KARTE?

Skriptzuordnungen werden verwendet, um Dateierweiterungen dem ISAPI-Handler zuzuordnen, der ausgeführt wird, wenn dieser Dateityp angefordert wird. Die Skriptzuordnung verfügt außerdem über eine optionale Einstellung, mit der überprüft wird, ob die der Anforderung zugeordnete physische Datei vorhanden ist, bevor die Verarbeitung der Anforderung zugelassen wird

Ein gutes Beispiel kann sein seen here

IIS 7 und höher

IIS 7.0 und höher wurde von Grund auf überarbeitet, um eine brandneue C ++ API-basierte ISAPI bereitzustellen.

IIS 7.0 und höher integriert die ASP.NET-Laufzeit in die Kernfunktionalität des Webservers und bietet eine einheitliche (einzelne) Anforderungsverarbeitungspipeline, die sowohl nativen als auch verwalteten Komponenten ausgesetzt ist, die als Module (IHttpModules) bezeichnet werden.

Dies bedeutet, dass IIS 7 Anforderungen, die für einen beliebigen Inhaltstyp eingehen, mit beiden verarbeitet NON ASP.NET Modules / native IIS modulesund ASP.NET modulesdie Anforderungsverarbeitung in allen Phasen bereitstellt. Dies ist der Grund, warum NON ASP.NET-Inhaltstypen (.html, statische Dateien) von .NET-Modulen verarbeitet werden können .

• Sie können neue verwaltete Module ( IHttpModule) erstellen, die für alle Anwendungsinhalte ausgeführt werden können, und Ihrer Anwendung einen erweiterten Satz von Anforderungsverarbeitungsdiensten bereitstellen.
• Neue verwaltete Handler hinzufügen ( IHttpHandler)

Im klassischen Modus funktioniert IIS mit ISAPI-Erweiterungen und ISAPI-Filtern direkt. Und verwendet zwei Pipe-Leitungen, eine für nativen Code und eine für verwalteten Code. Sie können einfach sagen, dass IIS 7.x im klassischen Modus genauso funktioniert wie IIS 6 und Sie keine zusätzlichen Vorteile aus den IIS 7.x-Funktionen ziehen.

Im integrierten Modus sind IIS und ASP.Net eng miteinander verbunden, anstatt wie im klassischen Modus von nur zwei DLLs auf Asp.net abhängig zu sein.