ASP.NET の基礎となるアーキテクチャを調査し、.NET ランタイムに入る

.NET ランタイムへの実際のエントリ ポイントは、文書化されていないクラスとインターフェイスで発生します (訳: もちろん、Reflector を使用して J を表示することはできます)。これらのインターフェイスについて知っている人は Microsoft 以外にはほとんどいません。また、Microsoft の担当者は熱心ではありません。彼らは、これらの実装の詳細については、ASP.NET を使用してアプリケーションを開発する開発者にはほとんど役に立たないと考えています。

ワーカー プロセス (IIS5 では ASPNET_WP.EXE、IIS6 では W3WP.EXE) は、.NET ランタイムと ISAPI DLL をホストし、COM オブジェクトの小さなアンマネージ インターフェイスを呼び出し、最終的に呼び出しを ISAPIRuntime クラスに送信します。インスタンス上 (注釈: 原文は ISAPIRuntime クラスのインスタンス サブクラスですが、ISAPIRuntime クラスは作成者の事務的ミスであると疑われるシールされたクラスです。または、ここでのサブクラスはサブクラスを意味しません)。ランタイムへのエントリは、IISAPIRuntime インターフェイスを実装します (呼び出し元の仕様では、このインターフェイスは COM インターフェイスです)。IUnknown に基づくこの基礎となる COM インターフェイスは、ISAPI から ASP.NET に拡張された事前定義されたインターフェイスです。インターフェイスとその呼び出し署名 (Lutz Roeder の優れた .NET Reflector ツール http://www.aisto.com/roeder/dotnet/ を使用) これは、この段階的なプロセスを調べるのに適した方法です。

図 3 - このインターフェイスをさらに詳しく知りたい場合は、Reflector を開いて System.Web.Hosting 名前空間をポイントします。ISAPI DLL は、ホストされた COM インターフェイスを呼び出して、ASP.NET へのアクセスを開きます。 ISAPI ECB を指すリンク。この ECB には、要求を受信し、IIS に応答を返すために使用される完全な ISAPI インターフェイスにアクセスする機能が含まれています

。 (IIS6 では直接関連しています) (IIS5 の名前付きパイプ経由)。このクラス内を調べると、次のシグネチャを持つ ProcessRequest 関数が見つかります:

[return: MarshalAs(UnmanagedType.I4)]

int ProcessRequest([In] IntPtr) ecb,

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

ecb パラメーターは、アンマネージド リソースとして ProcessRequest 関数に渡される ISAPI 拡張制御ブロック (拡張制御ブロック) です。 ISAPI ECB には、サーバー変数、フォーム変数の入力ストリーム、データをクライアントに書き戻すための出力ストリームなど、すべての低レベルのリクエスト情報が含まれています。これは基本的に ECB リファレンスで提供されます。 ISAPI リクエストによってアクセスできるリソースにアクセスするためのすべての機能。ProcessRequest は、このリソース (ecb) のマネージド コードへの最初の入り口および出口ポイントです。

このモードの ISAPI では、拡張機能はすぐに呼び出しを返します。ワーカー プロセスまたは IIS スレッドですが、ECB は現在のリクエストの有効期間中利用可能なままになります。ECB には、リクエストが処理されたことを (ecb.ServerSupportFunction メソッドを通じて) ISAPI に知らせるメカニズムが含まれています (注釈: 詳細については、

、

ECB が解放され、ASP.NET が管理する別のスレッドに処理が渡されます。

これを内部的に使用して、サーバー変数や POST データなどの現在のリクエストに関する情報を受信します。これにより、ASP.NET はリクエストが完了するかタイムアウトになるまでアクセス可能な状態を維持します。リクエストの処理が完了するまで通信を続けます。出力は (ecb.WriteClient() を使用して) ISAPI 出力ストリームに書き込まれ、リクエストが完了すると、ISAPI 拡張機能にリクエストの処理が完了したことが通知され、ECB が解放されます。

、

効率

的なアンマネージ ISAPI ECB の非常に「薄い」ラッパーであるため、この実装は非常に効率的です。

.NET ランタイムがロードされるのですが、このプロセスに関するドキュメントが見つかりませんでした。また、ネイティブ コードについて話しているため、ISAPI DLL を逆コンパイルする良い方法はありません。 (.NET ランタイムをロードするコード)

私ができる最善の推測は、ISAPI 拡張機能が ASP.NET にマップする拡張機能に対する最初の要求を受け取ると、ジョブ プロセスが .NET ランタイムをロードするということです。ランタイムが存在すると、独立したアプリケーション (ASP.NET プログラムを参照) の場合、アンマネージ コードは、指定された仮想ディレクトリの ISAPIRuntime のインスタンスを要求できます (まだ存在しない場合)。 ISAPIRuntime が起動されると、起動プロセスからアプリケーション ドメインに常に存在します。インスタンス化 (注釈: ISAPIRuntime のインスタンス化を参照する必要があります) は、

最初のときに

仮想ディレクトリの要求が来ると、System.Web.Hosting.AppDomainFactory.Create() 関数が呼び出され、ISAPIRuntime のインスタンスが作成されます。この呼び出しにより、アプリケーションの種類、モジュール名、および仮想ディレクトリ情報が受信されます。これは、アプリケーション ドメインを作成し、この仮想ディレクトリの ASP.NET プログラムを起動するために ASP.NET によって使用されます。 HttpRuntime インスタンス (注釈: 原文は This HttpRuntime 派生オブジェクトですが、HttpRuntime はシールされたクラスであると思われます)。それぞれの仮想ディレクトリ (つまり、ASP.NET アプリケーションがホストされている) は、別のアプリケーション ドメインでホストされ、特定の ASP が使用された場合にのみロードされます。 .NET プログラムが要求されると、ISAPI 拡張機能はこれらの HttpRuntime オブジェクトのインスタンスを管理し、要求された仮想ディレクトリに基づいて内部要求を正しい HttpRuntime オブジェクトにルーティングします。

図 4 - ISAPI リクエストは、文書化されていないクラス、インターフェイスを使用し、多くのファクトリ メソッドを呼び出して ASP.NET の HTTP パイプラインに送信されます。各 Web アプリケーション/仮想ディレクトリは独自のアプリケーション ドメインで実行され、呼び出し元 (注釈: ISAPI DLL) は参照を維持します。 IISAPIRuntime インターフェイスに送信して、ASP.NET 要求処理をトリガーします。