Letzte Nacht habe ich eine ASP.NET MVC-Anwendung bereitgestellt und festgestellt, dass es weniger Arbeit ist, mit IIS7 im integrierten Modus zu deployen. Meine Frage ist, was ist der Unterschied? Und welche Auswirkungen hat es, eins oder das 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 arbeitet. Tatsächlich ist ASP.NET in diesem Modus nur eine ISAPI-Erweiterung (aspnet_isapi.dll) und ein ISAPI-Filter (aspnet_filter.dll). IIS behandelt ASP.NET einfach als externes Plugin, das in ISAPI implementiert ist, und arbeitet damit wie eine Blackbox (und nur wenn es die Anfrage an ASP.NET weitergeben muss). In diesem Modus unterscheidet sich ASP.NET nicht viel von PHP oder anderen Technologien für IIS.
Im integrierten Modus hingegen handelt es sich um einen neuen Modus in IIS7, bei dem die IIS-Pipeline eng integriert ist (d.h. genau gleich) wie die ASP.NET-Anforderungspipeline. ASP.NET kann jede Anfrage sehen, die es möchte, und Dinge entlang des Weges manipulieren. ASP.NET wird nicht mehr als externes Plugin behandelt. Es ist vollständig in IIS integriert. In diesem Modus haben ASP.NET HttpModules im Grunde genommen fast die gleiche Kraft wie ein ISAPI-Filter haben könnte, und ASP.NET HttpHandlers können fast die gleiche Leistungsfähigkeit wie eine ISAPI-Erweiterung haben. In diesem Modus ist ASP.NET im Grunde ein Teil von IIS.
Ich bin mir nicht sicher, ob es korrekt ist zu sagen, dass asp.net ein Teil von IIS ist. Sie wirken wie separate (wenn auch integrierte) Produkte. Ich könnte mich irren.
@MehrdadAfshari Hat die Handhabung von HttpModules-Methoden/Events in iis7 mehr Funktionalität als in iis6? Kannst du das näher erläutern?
Integrierter Anwendungs-Pool-Modus
Wenn ein Anwendungspool im integrierten Modus ist, können Sie von der integrierten Anforderungsverarbeitungsarchitektur von IIS und ASP.NET profitieren. Wenn ein Worker-Prozess in einem Anwendungspool eine Anforderung erhält, durchläuft die Anforderung eine geordnete Liste von Ereignissen. Jedes Ereignis ruft die erforderlichen nativen und gemanagten Module auf, um Teile der Anforderung zu verarbeiten und die Antwort zu generieren.
Es gibt mehrere Vorteile beim Ausführen von Anwendungspools im integrierten Modus. Zunächst sind die Anforderungsverarbeitungsmodelle von IIS und ASP.NET in einheitsmodell integriert. Dieses Modell beseitigt Schritte, die zuvor in IIS und ASP.NET dupliziert wurden, wie z.B. Authentifizierung. Zusätzlich ermöglicht der integrierte Modus die Verfügbarkeit von gemanagten Features für alle Inhaltsarten.
Klassischer Anwendungs-Pool-Modus
Wenn ein Anwendungspool im Klassischen Modus ist, behandelt IIS 7.0 Anforderungen wie im Isolationsmodus des Worker-Prozesses von IIS 6.0. ASP.NET-Anforderungen durchlaufen zunächst native Verarbeitungsschritte in IIS und werden dann zur Verarbeitung von gemanagtem Code in der gemanagten Laufzeit an Aspnet_isapi.dll weitergeleitet. Schließlich wird die Anforderung wieder durch IIS geleitet, um die Antwort zu senden.
Diese Trennung der IIS- und ASP.NET-Anforderungsverarbeitungsmodelle führt zu Duplizierung einiger Verarbeitungsschritte, wie z.B. Authentifizierung und Autorisierung. Zusätzlich sind gemanagte Code-Features wie z.B. Formularauthentifizierung nur für ASP.NET-Anwendungen oder Anwendungen verfügbar, für die Sie alle Anforderungen so skriptiert haben, dass sie von aspnet_isapi.dll verarbeitet werden.
Stellen Sie sicher, dass Sie Ihre vorhandenen Anwendungen auf Kompatibilität im integrierten Modus testen, bevor Sie eine Produktionsumgebung auf IIS 7.0 aktualisieren und Anwendungen Anwendungspools im integrierten Modus zuweisen. Sie sollten eine Anwendung nur einem Anwendungspool im klassischen Modus hinzufügen, wenn die Anwendung im integrierten Modus nicht funktioniert. Zum Beispiel könnte Ihre Anwendung auf einem Authentifizierungstoken, das von IIS an die gemanagte Laufzeit übergeben wird, beruhen und aufgrund der neuen Architektur in IIS 7.0 bricht der Prozess Ihre Anwendung.
Entnommen von: Was ist der Unterschied zwischen DefaultAppPool und Classic .NET AppPool in IIS7?
Ursprüngliche Quelle: Einführung in die IIS-Architektur
Schlüsselsatz im letzten Absatz: "Sie sollten eine Anwendung nur einem Anwendungspool im klassischen Modus hinzufügen, wenn die Anwendung im integrierten Modus nicht funktioniert."
@JsonStatham - Ein Grund dafür ist, dass der integrierte Modus die ASP.NET-Übernahme nicht verwenden kann (Websites > Ihre Website > IIS > Authentifizierung). Wenn Sie eine Intranet-Site haben und die Windows-Authentifizierung verwenden, ist dies eine wichtige Überlegung. Link
IIS 6.0 und frühere Versionen :
ASP.NET integriert sich über eine ISAPI-Erweiterung, eine C-API (basiert auf der C-Programmiersprache) mit dem IIS und stellt sein eigenes Anwendungs- und Anforderungsverarbeitungsmodell bereit.
Dies hat effektiv zwei separate Serveranforderungs- bzw. -antwort-Pipelines offenbart, eine für native ISAPI-Filter und Erweiterungskomponenten und eine weitere für verwaltete Anwendungs-Komponenten. ASP.NET-Komponenten würden vollständig innerhalb der ASP.NET-ISAPI-Erweiterungs-Blase ausgeführt UND NUR für Anfragen, die auf ASP.NET in der IIS-Skriptzuordnungskonfiguration abgebildet sind.
Anfragen für nicht-ASP.NET-Inhaltstypen wie 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 Hauptbegrenzung dieses Modells war, dass die von den ASP.NET-Modulen und benutzerdefiniertem ASP.NET-Anwendungscode bereitgestellten Dienste NICHT für nicht-ASP.NET-Anfragen verfügbar waren
Was ist eine SCRIPT MAP ?
Skriptzuordnungen werden verwendet, um Dateierweiterungen mit dem ISAPI-Handler zu verknüpfen, der ausgeführt wird, wenn dieser Dateityp angefordert wird. Die Skriptzuordnung hat auch eine optionale Einstellung, die überprüft, ob die physische Datei, die mit der Anforderung verknüpft ist, vorhanden ist, bevor die Anforderung verarbeitet wird
Ein gutes Beispiel kann hier gesehen werden
IIS 7 und höher
IIS 7.0 und höher wurden von Grund auf neu entwickelt, um eine brandneue C++ API-basierte ISAPI bereitzustellen.
IIS 7.0 und höher integrieren die ASP.NET-Laufzeit mit der Kernfunktionalität des Webservers, wodurch eine vereinheitlichte(einzige) Anforderungsverarbeitungs-Pipeline bereitgestellt wird, die sowohl nativen als auch verwalteten Komponenten , bekannt als Module (IHttpModules), offenbart.
Dies bedeutet, dass der IIS 7 Anfragen für jeden Inhaltstyp verarbeitet, sowohl mit NICHT-ASP.NET-Modulen / nativen IIS-Modulen als auch ASP.NET-Modulen, die in allen Phasen die Anforderungsverarbeitung bereitstellen Deshalb können auch NICHT-ASP.NET-Inhaltstypen (.html, statische Dateien ) von .NET-Modulen verarbeitet werden.
IHttpModule), die die Fähigkeit haben, für alle Anwendungs-Inhalte auszuführen und einen erweiterten Satz von Anforderungsverarbeitungsdiensten für Ihre Anwendung bereitzustellen.IHttpHandler)
Im klassischen Modus arbeitet IIS direkt mit ISAPI-Erweiterungen und ISAPI-Filtern. Es verwendet zwei Pipelines, eine für nativen Code und eine für verwalteten Code. Man kann einfach sagen, dass im klassischen Modus IIS 7.x genauso funktioniert wie IIS 6 und man keine zusätzlichen Vorteile aus den Features von IIS 7.x erhält.
Im integrierten Modus sind IIS und ASP.Net enger gekoppelt, anstatt nur auf zwei DLLs von Asp.net wie im Fall des klassischen Modus zu setzen.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
11 Stimmen
Wie war es weniger Arbeit, mit dem integrierten Modus im Vergleich zum klassischen Modus bereitzustellen? Nur aus Neugier.
10 Stimmen
@Peter: URLs ohne Erweiterung müssen im klassischen Modus manuell zugeordnet werden.
3 Stimmen
Selbst im MVC Global.asax lauten die Hinweise: Für Anweisungen zur Aktivierung des klassischen Modus von IIS6 oder IIS7 besuchen Sie go.microsoft.com/?LinkId=9394801. Oder Sie können einfach den integrierten Modus aktivieren und die System.Web.Mvc-Assembly einbinden, dann funktioniert alles problemlos.