Erkundung der zugrunde liegenden Architektur von ASP.NET und Einstieg in die .NET-Laufzeitumgebung

Der eigentliche Einstiegspunkt in die .NET-Laufzeit liegt in einigen undokumentierten Klassen und Schnittstellen (Übersetzung: Natürlich können Sie Reflector verwenden, um J anzuzeigen. Außer Microsoft wissen nur sehr wenige Leute über diese Schnittstellen Bescheid, und die Microsoft-Leute sind nicht begeistert davon.) Sie glauben, dass diese Implementierungsdetails für Entwickler, die ASP.NET zum Entwickeln von Anwendungen verwenden, von geringem Nutzen sind.

Der Arbeitsprozess (ASPNET_WP.EXE in IIS5, W3WP.EXE in IIS6) hostet die .NET-Laufzeit und die ISAPI-DLL. Er (der Arbeitsprozess) ruft eine kleine nicht verwaltete Schnittstelle des COM-Objekts auf und sendet den Aufruf letztendlich an die ISAPIRuntime-Klasse. Auf einer Instanz (Anmerkung: Der Originaltext ist eine Instanzunterklasse der ISAPIRuntime-Klasse, aber die ISAPIRuntime-Klasse ist eine versiegelte Klasse, was vom Autor als Schreibfehler vermutet wird, oder Unterklasse bedeutet hier nicht Unterklasse Die erste). Der Eintrag in die Laufzeit lautet: Diese undokumentierte Klasse implementiert die IISAPIRuntime-Schnittstelle (für die Aufruferspezifikation ist diese Schnittstelle eine COM-Schnittstelle, die auf IUnknown basiert und eine vorgegebene Schnittstelle ist, die von ISAPI auf ASP.NET erweitert wurde). Schnittstelle und ihre Aufrufsignatur (mit dem hervorragenden .NET Reflector-Tool http://www.aisto.com/roeder/dotnet/). Dies ist eine gute Möglichkeit, diesen Schritt-für-Schritt-Prozess zu erkunden.

Abbildung 3 – Wenn Sie tiefer in diese Schnittstelle eintauchen möchten, öffnen Sie Reflector und verweisen Sie auf den System.Web.Hosting-Namespace. Die ISAPI-DLL öffnet den Zugriff auf ASP.NET, indem sie eine gehostete ASP.NET-Schnittstelle empfängt Link, der auf den verwalteten ISAPI-Zeiger verweist. Dieser ECB enthält die Möglichkeit, auf die vollständige ISAPI-Schnittstelle zuzugreifen, die zum Empfangen von Anforderungen und zum Zurücksenden von Antworten an IIS verwendet wird.

Die IISAPIRuntime-Schnittstelle dient als Schnittstellenpunkt zwischen nicht verwaltetem Code, der von ISAPI und ASP.NET ausgeht

(

direkt verwandt mit IIS6). (über Named Pipes in IIS5)

. ecb,

[In, MarshalAs(UnmanagedType.I4)] int useProcessModel);

der ecb-Parameter ist der ISAPI Extension Control Block (Extention Control Block), der als nicht verwaltete Ressource an die ProcessRequest-Funktion übergeben wird Grundlegende Eingabe- und Ausgabeschnittstelle, die mit ISAPI-Anforderungsobjekten verwendet wird, enthält im Wesentlichen alle Anforderungsinformationen auf niedriger Ebene, wie z. B. Servervariablen, Eingabeströme für Formularvariablen und Ausgabeströme zum Zurückschreiben von Daten an den Client Die gesamte Funktionalität für den Zugriff auf eine Ressource, auf die über ISAPI-Anfragen zugegriffen werden kann, ist der anfängliche Ein- und Ausstiegspunkt für diese Ressource (ecb), um

Anfragen asynchron zu verarbeiten Der Worker-Prozess oder IIS-Thread, aber die ECB bleibt für die gesamte Lebensdauer der aktuellen Anfrage verfügbar. Die ECB enthält einen Mechanismus, um ISAPI darüber zu informieren, dass die Anfrage verarbeitet wurde (über die ecb.ServerSupportFunction-Methode) (Anmerkung: Weitere Informationen , siehe den Artikel zur Entwicklung von ISAPI-Erweiterungen), wodurch die ECB sofort freigegeben wird und die Verarbeitung an einen separaten Thread übergeben wird, der von ASP.NET verwaltet

wird Verwenden Sie es intern, um Informationen über die aktuelle Anforderung zu erhalten, z. B. Servervariablen und POST-Daten. Außerdem bleiben die Informationen an den Server zurück, bis die Anforderung abgeschlossen ist oder das Zeitlimit abläuft Kommunizieren Sie weiterhin mit ihm, bis die Anforderungsverarbeitung abgeschlossen ist. Die Ausgabe wird in den ISAPI-Ausgabestream geschrieben (mithilfe von ecb.WriteClient()) und die ISAPI-Erweiterung wird benachrichtigt, dass die Anforderungsverarbeitung abgeschlossen ist, und gibt die ECB frei

nur

ein sehr „dünner“ Wrapper um das effiziente, nicht verwaltete ISAPI ECB sind

– ein wenig mysteriös

Die .NET-Laufzeit wird geladen. Ich habe keine Dokumentation zu diesem Prozess gefunden, und da es sich um nativen Code handelt, gibt es keine gute Möglichkeit, die ISAPI-DLL zu dekompilieren Finden Sie es heraus (der Code, der die .NET-Laufzeit lädt).

Die beste Vermutung, die ich anstellen kann, ist, dass der Job die .NET-Laufzeit lädt, wenn die ISAPI-Erweiterung die erste Anforderung für eine Erweiterung erhält, die ASP.NET zugeordnet ist. Sobald die Laufzeit vorhanden ist, kann nicht verwalteter Code eine Instanz von ISAPIRuntime für ein angegebenes virtuelles Verzeichnis anfordern, sofern dieses noch nicht vorhanden ist. Jedes virtuelle Verzeichnis verfügt über eine eigene Anwendungsdomäne (AppDomain), wenn eine unabhängige Anwendung (bezogen auf ein ASP.NET-Programm) vorhanden ist. Wird gestartet, ist ISAPIRuntime seit dem Startvorgang immer in der Anwendungsdomäne vorhanden (Anmerkung: sollte sich auf die Instanziierung von ISAPIRuntime beziehen). Dies geschieht, weil die Schnittstellenmethoden

beim ersten Mal

Wenn eine Anforderung für ein virtuelles Verzeichnis eingeht, wird die Funktion System.Web.Hosting.AppDomainFactory.Create() aufgerufen, um eine Instanz von ISAPIRuntime zu erstellen. Dadurch wird der Startvorgang der Anwendung gestartet. Dieser Aufruf empfängt den Typ, den Modulnamen und die Informationen zum virtuellen Verzeichnis , das von ASP.NET verwendet wird, um die Anwendungsdomäne zu erstellen und das ASP.NET-Programm für dieses virtuelle Verzeichnis zu starten. (Anmerkung: Der Originaltext ist dieses von HttpRuntime abgeleitete Objekt, aber HttpRuntime ist eine versiegelte Klasse, was vermutet wird Dies soll ein Fehler im Originaltext sein) werden in einer neuen Anwendungsdomäne erstellt (d. h. eine ASP.NET-Anwendung wird in einer separaten Anwendungsdomäne gehostet) und werden nur geladen, wenn ein bestimmtes ASP Das .NET-Programm wird angefordert. Die ISAPI-Erweiterung verwaltet Instanzen dieser HttpRuntime-Objekte und leitet interne Anforderungen basierend auf dem angeforderten virtuellen Verzeichnis weiter.

Abbildung 4 – ISAPI-Anfragen werden mithilfe einiger undokumentierter Klassen, Schnittstellen und dem Aufruf vieler Factory-Methoden an die HTTP-Pipeline von ASP.NET gesendet. Jede Webanwendung/virtuelles Verzeichnis wird in ihrer eigenen Anwendungsdomäne ausgeführt, und der Aufrufer (Anmerkung: ISAPI-DLL) verwaltet eine Referenz an die IISAPIRuntime-Schnittstelle, um die ASP.NET-Anforderungsverarbeitung auszulösen.