ASP.NET と IIS 7 の統合

[アーティクル]
07/19/2023

はじめに

ASP.NET は、そのリリースから、Windows/IIS プラットフォーム上で Web アプリケーションを開発するための最適なプラットフォームでした。 ASP.NET 2.0 は、Web アプリケーション開発を新しいレベルに進化させ、開発者は、これまで以上に強力なアプリケーションを迅速に構築できるようになりました。

IIS 7 以降では、ASP.NET ランタイムの機能拡張モデルがコアサーバーと統合されるため、ASP.NET がさらに改善されます。これにより、開発者は、機能が少ない IIS C++ API を使用する代わりに、ASP.NET 2.0 と .NET Framework の豊富な機能で IIS サーバーを完全に拡張できます。また、既存の ASP.NET アプリケーションも、フォーム認証、ロール、すべてのコンテンツの出力キャッシュなどの既存の ASP.NET 機能を使用して、より緊密な統合からすぐにメリットを得ることができます。

IIS では、既定で改善された ASP.NET 統合が提供されますが、選択肢もあります。つまり、IIS では、同じサーバーで並行して使用できる新しい ASP.NET 統合モードと古い統合モードの両方がサポートされています。

この記事では、ASP.NET 統合モードによって導入された機能強化、2 つのモードのアーキテクチャ、および ASP.NET アプリケーションの統合モードを選択して構成する方法について説明します。

IIS 7 以降の ASP.NET の機能強化

IIS の ASP.NET 統合の向上により、既存のアプリケーションが強化され、新しいアプリケーションが次の方法で ASP.NET 機能を利用できるようになります。

ASP.NET サービスはすべてのコンテンツタイプで使用できます。 以前は、フォーム認証、ロール、URL 認証、出力キャッシュなどの ASP.NET 機能は、ASPX ページなどの ASP.NET コンテンツタイプでのみ使用可能でした。静的ファイル、ASP ページ、およびその他のコンテンツタイプは、これらのサービスからメリットを得ることができませんでした。

IIS では、すべての ASP.NET サービスがすべてのコンテンツに対して一様に提供されます。たとえば、ASP.NET フォーム認証、メンバーシップ、ログインコントロールに基づいて構築された既存の ASP.NET 2.0 アクセス制御ソリューションを使用して、イメージや ASP ページを含むすべての Web コンテンツを保護できます。

ASP.NET を使用して IIS を完全に拡張します。 以前のバージョンの IIS では、ASP.NET のランタイム制限により、ネイティブの ISAPI フィルターまたは機能拡張モードを使用して頻繁にサーバー機能拡張を開発する必要がありました。

IIS を使用すると、ASP.NET モジュールは、ネイティブ (C++) サーバー API で開発されたモジュールと同じランタイムの忠実さで、サーバーパイプラインに直接プラグインできます。 ASP.NET モジュールは、要求処理パイプラインのすべてのランタイムステージで実行でき、ネイティブモジュールに対して任意の順序で実行できます。 ASP.NET API も拡張され、以前よりも厳密に要求処理を制御できます。

統合サーバーランタイム。 また、ASP.NET の統合が緊密になり、IIS と ASP.NET の間で多くの機能が統合されます。

IIS では、IIS と ASP.NET モジュールとハンドラーの統合構成が提供されます。カスタムエラーやトレースを含む他の多くの機能が統合され、管理が容易になり、統一されたアプリケーション設計が可能になっています。

ASP.NET 統合アーキテクチャ

IIS 6.0 以前のリリースでは、ASP.NET は IIS ISAPI 拡張機能として実装されていました。

これらの以前のリリースでは、IIS は ASP.NET コンテンツタイプに対する要求を処理した後、その要求を ASP.NET 要求パイプラインとページフレームワークをホストする ASP.NET ISAPI DLL に転送しました。 ASP ページや静的ファイルなどの非 ASP.NET コンテンツに対する要求は、IIS またはその他の ISAPI 拡張機能によって処理され、ASP.NET には認識されませんでした。

このモデルの主な制限は、ASP.NET モジュールによって提供されるサービスとカスタム ASP.NET アプリケーションコードが非 ASP.NET 要求に対して使用できなかったということです。さらに、ASP.NET モジュールは、ASP.NET 実行パスの前後に発生した IIS 要求処理の特定の部分に影響を与えることができませんでした。

図 1: IIS 6.0 と ASP.NET パイプライン

IIS では、ASP.NET 要求処理パイプラインによって IIS パイプラインが直接オーバーレイされ、基本的に、それにプラグインインするのではなく、その上にラッパーが提供されます。

IIS は、ネイティブ IIS モジュールと ASP.NET モジュールの両方で、あらゆるコンテンツタイプの到着した要求を処理し、すべてのステージで要求処理を提供します。これにより、フォーム認証や出力キャッシュなどの ASP.NET モジュールによって提供されるサービスを、ASP ページ、PHP ページ、静的ファイルなどの要求に使用できます。

サーバーパイプラインに直接プラグインする機能により、ASP.NET モジュールは任意の IIS 機能を置き換え、その前または後に実行することができます。これにより、たとえば、メンバーシップサービスと SQL Server ユーザーデータベースを使用して、Windows アカウントでのみ動作する組み込みの IIS 基本認証機能を置き換えるために作成されたカスタム ASP.NET 基本認証モジュールが可能になります。

さらに、拡張 ASP.NET API は、直接統合を使用して、より多くの要求処理タスクを有効にします。たとえば、ASP.NET モジュールは、他のコンポーネントが要求を処理する前に要求ヘッダーを変更できます。ASP アプリケーションの実行前に Accept-Language ヘッダーを挿入すると、ユーザー設定に基づいて、ローカライズされたコンテンツがクライアントに強制的に送り返されます。

図 2: IIS 7 以降の統合モード

ランタイムの統合により、IIS と ASP.NET は同じ構成を使用して、サーバーモジュールの有効化と順序付け、およびハンドラーマッピングの構成を実行できます。その他の統合機能には、トレース、カスタムエラー、出力キャッシュが含まれます。

互換性

特に、このアーキテクチャは、ASP.NET ランタイムアーキテクチャと API を維持し、これにより、既存の ASP.NET アプリケーションとサービスをインストール後に使用できます。いくつかの変更により、既存の ASP.NET アプリケーションとサービスで新しい ASP.NET 機能を利用できます。

同様に、開発者は、ランタイム統合のメリットを活用しながら、使い慣れた ASP.NET API で新しいアプリケーションの作成を続けることができます。

IIS は、統合モードでは満たされない特定の互換性要件を持つ ASP.NET アプリケーション用に、引き続きクラシック ASP.NET モードを提供します。管理者は、アプリケーションプールごとに目的の統合モードを選択できます。これにより、新しいモードとクラシック ASP.NET モードのどちらを使用するアプリケーションも、同じサーバー上で並行して機能できます。

ASP.NET アプリケーションの IIS 7 以降の統合モードへの移行

IIS では、ASP.NET は既定で新しい統合モードで動作するように構成されています。これにより、アプリケーションは最小限の変更で統合モードの拡張機能を利用できます。

構成の統合により、一部のアプリケーションは統合モードで適切に動作させるために移行が必要になる場合があります。既定では、サーバーは移行に関するサポートを提供します。移行が必要なアプリケーションが検出されると、アプリケーションの移行を要求するエラーメッセージが返されます。

次の構成では、移行エラーが発生します。

アプリケーションの Web.config ファイルが <httpModules> 構成を定義する。
アプリケーションは、新しい ASP.NET モジュールを読み込むか、既存のモジュールを削除します。
統合モードでは、ASP.NET モジュールは、統合された <system.webServer>/<modules> 構成セクションでネイティブモジュールで指定されます。
<system.web>/<httpModules> 構成セクションで指定された ASP.NET モジュールを、有効にするには新しい構成セクションに移動する必要があります。その後、新しい ASP.NET モジュールを統合された <modules> セクションに直接追加する必要があります。
アプリケーションの Web.config ファイルが <httpHandlers> 構成を定義する。
アプリケーションでは、一部のコンテンツタイプに対してカスタムハンドラーマッピングが使用されます。
統合モードでは、ASP.NET ハンドラーマッピングを有効にするには、統合された <system.webServer>/<handlers> 構成セクションで指定する必要があります。その後、新しい ASP.NET ハンドラーマッピングを統合された <handlers> セクションに直接追加する必要があります。
このセクションでは、ASP.NET <httpHandlers> 構成と IIS スクリプトマップ構成の両方を置き換えます。以前はどちらも、ASP.NET ハンドラーマッピングを設定するように構成する必要がありました。
アプリケーションの Web.config ファイルが、<identity impersonate="true" /> 構成を定義する。
アプリケーションは、イントラネットアプリケーションで最も一般的なクライアント資格情報を偽装します。統合モードでは、一部の初期の要求処理ステージではクライアントの偽装を使用できません。ほとんどの場合、これは問題ではなく、移行エラーをオフにすることができます。それ以外の場合は、クラシック ASP.NET モードを使用して実行するようにこのアプリケーションを構成する必要があります。

移行エラーが生成される場合、通常、アプリケーション構成を移行するか (上記のケース 1 と 2 で推奨)、クラシック ASP.NET モードを使用するようにアプリケーションを移動できます (ケース 3 で推奨)。

アプリケーション構成の移行

IIS は、移行を実行するための AppCmd.exe コマンドラインツールを使用してアプリケーションを移行します。移行エラーメッセージには、コマンドラインウィンドウで実行されるコマンドが含まれています。このコマンドは、アプリケーションを統合モードに即座に移行するために、管理者ユーザーの権限で実行する必要があります。

移行コマンドの基本的な形式は次のとおりです。

%windir%\system32\inetsrv\APPCMD.EXE migrate config <Application Path>

ここで <Application Path> は、サイト名を含むアプリケーションの仮想パスです ("Default Web Site/app1" など)。

移行が完了すると、アプリケーションは統合モードとクラシックモードの両方で問題なく実行されます。

Note

移行後に構成を変更した場合、サーバーは再び移行するように求めるメッセージを表示しません。最初の移行後、2 つのモード間で構成の同期が維持されていることを確認する必要があります。 AppCmd.exe コマンドラインツールを使用して、アプリケーションをもう一度手動で移行できます。

クラシック ASP.NET 統合モードに戻る

クラシック ASP.NET モードに戻す場合は、クラシックモードで実行するように構成されたアプリケーションプールにアプリケーションを移動します。他のアプリケーションは、クラシックモードアプリケーションと並行して新しい統合モードで引き続き実行されます。

アプリケーションをクラシック ASP.NET モードに移動する方法の詳細については、「アプリケーションの ASP.NET モードを変更する」を参照してください。

移行エラーメッセージを無効にする

構成を手動で移行した場合、または構成を移行せずに統合モードのままにする場合 (推奨されません)、アプリケーションの Web.config ファイルに次の行を追加することで、移行エラーメッセージを無効にすることができます。

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

Note

AppCmd.exe コマンドラインツールを使用して構成を移行した後、サーバーは自動的にエラーメッセージを無効にします。

移行エラーメッセージを手動で無効にした場合は、サポートされていない構成に関する警告がサーバーによって提供されなくなるため、アプリケーションが統合モードで正しく動作することを確認する必要があります。

アプリケーションの ASP.NET モードを変更する

統合 ASP.NET モードでアプリケーションが正常に動作しない場合は、別のアプリケーションプールに移動することで、アプリケーションをクラシック ASP.NET モードに移動できます。各アプリケーションプールは、目的の ASP.NET 統合モードを使用するように個別に構成されます。これにより、異なる ASP.NET 統合モードを使用するアプリケーションのグループを、同じサーバー上で並列で実行できます。

アプリケーションの ASP.NET 統合モードを変更するには:

目的のモードを使用するように構成されたアプリケーションプールを検索または作成します。
既定では、すべての新しいアプリケーションプールは統合モードで実行されます。
ASP.NET セットアップでは、クラシック ASP.NET 統合モードで実行される "Classic .NET AppPool" という名前のアプリケーションプールが提供されます。統合モードで実行できないアプリケーションには、このアプリケーションプールを使用できます。
IIS 管理ツールまたは AppCmd.exe コマンドラインツールを使用するか、アプリケーションプール構成を手動で編集して、既存のアプリケーションプールの ASP.NET モードを変更することもできます。
そのアプリケーションプールを使用するようにアプリケーションを設定します。
各アプリケーションは、特定のアプリケーションプールを使用するように構成されます。既定では、すべてのアプリケーションで "DefaultAppPool" という名前の既定のアプリケーションプールが使用され、統合モードで実行されます。
IIS 管理ツールまたは AppCmd.exe コマンドラインツールを使用するか、アプリケーション構成を手動で編集して、アプリケーションのアプリケーションプールを変更することができます。

アプリケーションの ASP.NET バージョンの選択

これまで、IIS では複数のバージョンの ASP.NET/CLR が並列でサポートされています。たとえば、IIS では、.NET Framework v1.1 と v2.0 を使用して、同じサーバーで ASP.NET アプリケーションを実行できます。このサポートは、対応するバージョンの ASPNET_isapi.dl をマッピングし、IIS スクリプトマップ構成を使用して ASP.NET コンテンツの要求を処理することで提供されました。

たとえば、次のスクリプトマップ構成を使用して、並列サポートを有効にすることができます。

/app1 上の ASP.NET v1.1 アプリケーション:
*.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll
/app2 上の ASP.NET v2.0 アプリケーション:
*.aspx -> d:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll

アプリケーションが *.aspx 要求を受け取ると、IIS は指定されたaspnet_isapi.dll を読み込みます。これにより、適切な CLR バージョンをワーカープロセスに読み込み、要求を処理します。

ASP.NET では、次の方法で並列スクリプトマップを構成することもできます。

ASP.NET MMC 拡張機能 使用する ASP.NET のバージョンを選択すると、拡張機能によってアプリケーションのスクリプトマップが、aspnet_isapi.dll の正しいバージョンを指すよう自動的に構成されます。
ASP.NET aspnet_regiis.exe。 –i オプションと –r オプションを使用して、対応する ASP.NET バージョンを指すスクリプトマップをインストールします。

残念ながら、1 つのワーカープロセスには CLR バージョンを 1 つしか読み込むことができないので、異なるバージョンの ASP.NET を使用する 2 つのアプリケーションが同じアプリケーションプール内に存在するように構成されていないことを確認する必要があります。この一般的な間違いが発生すると、最初の要求で対応するaspnet_isapi.dll の CLR が読み込まれ、その後の同じアプリケーションプール内の他のバージョンへの要求は失敗します。

IIS は、アプリケーションプールが、アプリケーションを実行するために選択した ASP.NET バージョンであることを認識します。そのため、アプリケーションプールに読み込まれる CLR/ASP.NET のバージョンは、アプリケーションプール構成で明示的に構成されます。既定では、IIS はワーカープロセスを読み込むときに、この設定で指定された CLR を事前に読み込みます (バージョンが空に構成されている場合を除く)。

アプリケーションプールは .NET Framework のバージョン管理の境界であるため、次の手順を実行して、ASP.NET アプリケーションのバージョンを変更できます。

目的の ASP.NET バージョンを使用するアプリケーションプールにアプリケーションを移動します。
既定では、アプリケーションで "DefaultAppPool" という名前の既定のアプリケーションプールが使用され、ASP.NET v2.1 が統合モードで実行されます。アプリケーションを "Classic .NET AppPool" に移動して、ASP.NET v2.1 クラシックモードで実行するか、または選択した別のアプリケーションプールで実行します。
目的の ASP.NET バージョンを使用するように、アプリケーションが実行されているアプリケーションプールを構成します。
既定では、統合モードで ASP.NET v2.1 を実行するようにすべての新しいアプリケーションプールが構成されます。

Note

aspnet_regiis /i または /r オプションを使用して、特定のアプリケーション用にまたはグローバルに ASP.NET のバージョンを構成しないでください。

IIS では、構成されている CLR バージョンとアプリケーションプールのマネージド統合モードに応じて、事前に条件付けされたハンドラーマッピングを使用して、ハンドラーマッピングの適切なセット (クラシックモードで ASPNET_isapi.dll に、統合モードではマネージドハンドラーの種類に直接マッピング) を自動的に選択します。 ASP.NET 2.0 セットアップでは、これらのハンドラーマッピングがサーバーレベルでインストールされます。

統合 ASP.NET モードを活用する

IIS では、ASP.NET アプリケーションは既定で統合モードで実行されます。ただし、緊密な統合によって提供される利点を利用するには、アプリケーション構成にいくつかの変更を加える必要があります。統合モードを利用してアプリケーションに強力な機能を提供する新しい ASP.NET コンポーネントを開発することもできます。

すべてのコンテンツタイプ用の ASP.NET サービスを有効にする

統合モードでは、ASP.NET モジュールによって提供されるサービスは、すべてのコンテンツタイプの要求に使用できます。ただし、既定では、下位互換性のために、ASP.NET モジュールは、コンテンツを ASP.NET する要求に対してのみ実行するように構成されています。

これを行うには、サーバーレベルで構成セクションの各 ASP.NET モジュールに managedHandler の前提条件をアタッチします。

<modules> 
     <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" 
             preCondition="managedHandler" />
     <add name="UrlAuthorization" type="System.Web.Security.UrlAuthorizationModule" 
             preCondition="managedHandler" />
    ...
</modules>

前提条件は、モジュールが実行されるかどうかを判断するために、すべての要求でサーバーが評価するルールです。 managedHandler の前提条件は、ASP.NET ハンドラーにマップされているコンテンツタイプへの要求にのみ当てはまります。

ASP.NET モジュールによって提供される機能をすべての要求に適用するには、モジュールエントリを削除してから、アプリケーションのルート Web.config ファイルに前提条件なしで再び追加します。

アプリケーション全体に対して ASP.NET フォーム認証を有効にするには、次のように Web.config ファイルを変更します。

<modules> 
    <remove name="FormsAuthentication" /> 
    <add name="FormsAuthentication" type="System.Web.Security.FormsAuthenticationModule" /> 
    …
</modules>

この変更により、FormsAuthentication モジュールはアプリケーション内のすべての要求に対して実行されます。これにより、フォーム認証を使用してすべてのアプリケーションコンテンツを保護できます。統合モードを利用してすべてのアプリケーションコンテンツにフォーム認証を提供する方法の詳細については、統合パイプラインモードの活用に関するチュートリアルを参照してください。

また、ショートカットを使用して、"managedHandler" の前提条件に関係なく、すべてのマネージド (ASP.NET) モジュールがアプリケーション内のすべての要求に対して実行されるようにすることもできます。 "managedHandler" の前提条件を削除するように各モジュールエントリを構成せずにすべてのマネージドモジュールをすべての要求に対して実行できるようにするには、<modules> セクションの runAllManagedModulesForAllRequests プロパティを使用します。

<modules runAllManagedModulesForAllRequests="true" />

これを使用すると、"managedHandler" の前提条件は効果がなくなり、すべての要求に対してすべてのマネージドモジュールが実行されます。

他の ASP.NET モジュールをアプリケーション全体に適用できるようにする方法を試してください。たとえば、ASP.NET 出力キャッシュモジュールを使用してキャッシュ ASP ページを出力するか、URL 認証とロールマネージャーを使用して写真のアクセス制御規則を構成します。または、Web サイト全体で ASP.NET の機能を使用できるようにする独自のモジュールを開発します。

より強力な ASP.NET サービスの構築

統合モードでは、ASP.NET モジュールはすべてのコンテンツにサービスを適用します。さらに、ASP.NET モジュールは統合モードで統合要求処理パイプラインで実行されるため、同じ要求処理ステージをサブスクライブし、ネイティブサーバーモジュールと同じタスクを実行します。同時に、ASP.NET API はほとんど変わっていませんが、以前は利用できなかった機能をロック解除するいくつかの重要な追加機能があります。

ランタイムの忠実さ

統合モードでは、モジュールに公開されている ASP.NET 要求処理ステージは、IIS パイプラインの対応するステージに直接接続されます。完全なパイプラインには、次のステージが含まれています。これらは、ASP.NET で HttpApplication イベントとして公開されます。

BeginRequest。要求の処理が開始されます。
AuthenticateRequest。要求が認証されます。 IIS および ASP.NET 認証モジュールは、このステージをサブスクライブして認証を実行します。
PostAuthenticateRequest。
AuthorizeRequest。要求が承認されている IIS および ASP.NET 承認モジュールは、認証されたユーザーが要求されたリソースにアクセスできるかどうかをチェックします。
PostAuthorizeRequest。
ResolveRequestCache。キャッシュモジュールは、この要求に対する応答がキャッシュに存在するかどうかをチェックし、残りの実行パスに進む代わりにそれを返します。 ASP.NET 出力キャッシュ機能と IIS 出力キャッシュ機能の両方が実行されます。
PostResolveRequestCache。
MapRequestHandler。このステージは ASP.NET の内部ステージであり、要求ハンドラーを決定するために使用されます。
PostMapRequestHandler。
AcquireRequestState。要求の実行に必要な状態が取得されます。 ASP.NET セッション状態モジュールとプロファイルモジュールは、それらのデータを取得します。
PostAcquireRequestState。
PreExecuteRequestHandler。ハンドラーの実行前のすべてのタスクが実行されます。
ExecuteRequestHandler。要求ハンドラーが実行されます。 ASPX ページ、ASP ページ、CGI プログラム、および静的ファイルが提供されます。
PostExecuteRequestHandler
ReleaseRequestState。要求状態の変更が保存され、ここで状態がクリーンアップされます。 ASP.NET セッション状態モジュールとプロファイルモジュールは、このステージをクリーンアップに使用します。
PostReleaseRequestState。
UpdateRequestCache。応答は、後で使用するためにキャッシュに格納されます。 ASP.NET 出力キャッシュモジュールと IIS 出力キャッシュモジュールが、応答をキャッシュに保存するために実行されます。
PostUpdateRequestCache。
LogRequest。このステージでは、要求の結果がログに記録され、エラーが発生した場合でも実行が保証されます。
PostLogRequest。
EndRequest。このステージは、最終的な要求のクリーンアップを実行し、エラーが発生した場合でも実行が保証されます。

使い慣れた ASP.NET API を使用することで、IIS モジュールと同じステージで実行できるため、以前はネイティブの ISAPI フィルターと拡張機能でのみアクセスできたタスクをマネージドコードで実行できるようになりました。

たとえば、次の操作を行うモジュールを記述できるようになりました。

URL の書き換えやセキュリティフィルター処理など、処理が行われる前に要求をインターセプトします。
組み込みの認証モードを置き換えます。
要求ヘッダーなど、受信要求のコンテンツを変更します。
すべてのコンテンツタイプの送信応答をフィルター処理します。

カスタム ASP.NET 認証モジュールを使用して IIS を拡張する方法の良い例については、.NET を使用した IIS 7 以降のモジュールの開発に関する記事を参照してください。

拡張 ASP.NET API

ASP.NET API は以前のリリースとの下位互換性を維持しています。これにより、既存のモジュールを変更せずに IIS 7 以降で動作させ、コードを変更せずにすべてのアプリケーションコンテンツに適用できます。

ただし、IIS 統合モード用に記述されたモジュールでは、いくつかの追加 API を利用して、以前は使用できなかった主要な要求処理シナリオを有効にすることができます。

新しい HttpResponse.Headers コレクションを使用すると、モジュールは、他のアプリケーションコンポーネントによって生成される応答ヘッダーを検査および操作できます。たとえば、ASP ページによって生成される Content-Type ヘッダーを変更して、ブラウザーでダウンロードダイアログボックスを表示できます。 HttpResponse クラスの Cookie コレクションも強化され、要求処理の一部として生成される Cookie を、それが ASP.NET の外部で作成した場合でも変更できます。

HttpRequest.Headers コレクションは書き込み可能です。これにより、モジュールは受信要求ヘッダーを操作できます。これを使用して、他のサーバーコンポーネントの動作を変更します。たとえば、Accept-Language ヘッダーの値を動的に変更することで、ローカライズされたアプリケーションに強制的に別の言語でクライアントに応答させることができます。

最後になりますが、HttpRequest.ServerVariables コレクションが書き込み可能になり、IIS サーバー変数を設定できるようになりました。 ASP.NET モジュールでは、この機能を使用して、IIS によって提供される値を変更したり、PHP などの他のアプリケーションフレームワークに表示される新しいサーバー変数を作成したりできます。

ランタイムの統合

統合モードでは、新しい API に加えて、既存の ASP.NET 機能を使用して、アプリケーションにより多くの価値を提供できます。

System.Diagnostics.Trace クラスや ASP.NET ページトレース機能など、ASP.NET によって提供されるトレース機能によって、IIS トレースシステムにトレース情報が出力されるようになりました。これにより、IIS コンポーネントと ASP.NET コンポーネントの両方による要求処理中に生成されるトレース情報を 1 つのログファイルに記録できるため、サーバーの問題の診断が容易になります。

ASP.NET 応答フィルター処理機能では、応答をクライアントに送信する前に Stream インターフェイスを使用して応答を変更できるので、非 ASP.NET コンテンツのフィルター処理が可能になります。そのため、すべてのサーバーコンテンツについて ASP.NET フィルター処理使用することも、処理したいコンテンツの要求についてのみフィルターを選択的にインストールすることもできます。この機能を使用すると、このコンテンツが ASPX ページまたは静的ファイルのどちらから取得されたかに関係なく、サイトの応答に特定のコンテンツを挿入または検閲するフィルター機能を記述できます。

まとめ

IIS 7 以降の ASP.NET 統合により、ASP.NET の可能性が最大限に解放され、開発者は、ASP.NET と .NET Framework の使いやすい豊富な機能を使用して、強力なサーバーコンポーネントを作成できます。既存のアプリケーションに ASP.NET 統合モードを活用する方法の詳細については、統合パイプラインモードの活用に関する記事を参照してください。新しい ASP.NET コンポーネントをビルドしてサーバーを拡張する方法については、.NET を使用した IIS 7 以降のモジュールの開発に関する記事を参照してください。

次の方法で共有

ASP.NET と IIS 7 の統合

はじめに

IIS 7 以降の ASP.NET の機能強化

ASP.NET 統合アーキテクチャ

互換性

ASP.NET アプリケーションの IIS 7 以降の統合モードへの移行

アプリケーション構成の移行

クラシック ASP.NET 統合モードに戻る

移行エラーメッセージを無効にする

アプリケーションの ASP.NET モードを変更する

アプリケーションの ASP.NET バージョンの選択

統合 ASP.NET モードを活用する

すべてのコンテンツタイプ用の ASP.NET サービスを有効にする

より強力な ASP.NET サービスの構築

ランタイムの忠実さ

拡張 ASP.NET API

ランタイムの統合

まとめ

フィードバック

フィードバック

その他のリソース

次の方法で共有

ASP.NET と IIS 7 の統合

はじめに

IIS 7 以降の ASP.NET の機能強化

ASP.NET 統合アーキテクチャ

互換性

ASP.NET アプリケーションの IIS 7 以降の統合モードへの移行

アプリケーション構成の移行

クラシック ASP.NET 統合モードに戻る

移行エラー メッセージを無効にする

アプリケーションの ASP.NET モードを変更する

アプリケーションの ASP.NET バージョンの選択

統合 ASP.NET モードを活用する

すべてのコンテンツ タイプ用の ASP.NET サービスを有効にする

より強力な ASP.NET サービスの構築

ランタイムの忠実さ

拡張 ASP.NET API

ランタイムの統合

まとめ

フィードバック

フィードバック

その他のリソース

移行エラーメッセージを無効にする

すべてのコンテンツタイプ用の ASP.NET サービスを有効にする