ASP.NET 1.1 から Windows Vista および Windows Server 2008 の IIS 7 へのアップグレード

公開日: 2007 年 12 月 18 日 (作業者: iisteam (英語))

更新日: 2008 年 3 月 5 日 (作業者: iisteam (英語))

はじめに

Windows Vista™ オペレーティング システムに移行した ASP.NET アプリケーション開発者は、IIS 7 でこれまでの IIS のバージョンから大きな前進を見ることができます。IIS 7 統合モードでは、特にセキュリティが強化され、新しいアプリケーションの可能性が広がっています。

Windows Vista に移行する開発者のほとんどは、Microsoft Windows® XP オペレーティング システムから Windows Vista へのアップグレードであり、その過程で ASP.NET アプリケーションをアップグレードします。これ以外の場合は、他の Windows オペレーティング システムで開発した ASP.NET アプリケーションを Windows Vista にインストールします。

この記事では、アプリケーションを新しいオペレーティング システムで動作させるために必須の、インストール後およびアップグレード後の重要な構成ステップを説明します。また、ASP.NET アプリケーションに影響するクラシック モードと IIS 7 統合モードの差異、および既知の問題の回避方法を解説します。

IIS 7 の大きな向上点の 1 つに、統合パイプライン機能があります。これは、マネージ コードまたは非マネージ コードのどちらのアプリケーションからでも、Web アプリケーションで単一の要求処理パイプラインを使用できるようになる機能です。さらに、新しいパイプライン モデルによって、同じ機能を 2 つの別々の実装で処理するという冗長な動作がなくなりました。

たとえば、過去のリリースの IIS と ASP.NET では、イベントやハンドラー モジュールへのアクセスを共有しない、別々の要求パイプラインが実装されていました。認証は、各パイプライン内で独立して実行されます。この新しいモデルでは、認証は IIS と ASP.NET で一度に実行できます。

この統合には、その他に以下のようなメリットがあります。

• IIS 7 コンテンツ タイプ (静的、クラシック ASP ページなど) で動作する、フォーム認証および役割などの ASP.NET サービス。
• ISAPI 拡張や CGI だけではなく、マネージ コードおよび ASP.NET パイプライン モジュールで拡張できる IIS 7 機能。
• イベント トレースおよびエラー ログの統合によって簡単になったトラブルシューティング。
• ASP.NET と IIS 7 の間でのアプリケーション構成の共有。

この記事では、IIS の旧バージョンから IIS 7 に移行する ASP.NET アプリケーションの互換性の問題を検討します。特に、クラシック モードから統合モードの統合パイプライン使用に移行する際の相違点に焦点を当てます。

ASP.NET と IIS 7 の統合の特長とメリットの概要については、記事「ASP.NET と IIS 7 の統合」を参照してください。

IIS の旧バージョンから Windows Vista へのアップグレード

Windows Vista の各エディションで利用できる IIS 7 を、次の表に示します。

Windows Vista のエディション	IIS 7 の使用可否
Home Basic	不可
Home Premium	可能
Business	可能
Ultimate	可能

Windows Vista での ASP.NET アップグレード シナリオ

次の表に、Windows オペレーティング システムの旧バージョン上の ASP.NET を、Windows Vista 上の ASP.NET にアップグレードする際にサポートされる経路の概要を示します。問題点が記載されている場合、以降のセクションを参照して、アップグレードの制約と制限について詳細情報を確認してください。

この表には、サーバー OS バージョンからクライアント OS バージョンへのアップグレードが利用できないことも示されています。現在サーバー OS がインストールされているコンピューターには、Vista をクリーン インストールする必要があります。

オペレーティング システム	IIS バージョン	.NET Framework バージョン	Windows Vista と IIS 7 にアップグレードする際の注意点
Windows 2000 Server	IIS 5.0	1.0, 1.1, 2.0	Windows Vista にはアップグレードできません。
Windows 2000 Professional	IIS 5.0	1.0, 1.1, 2.0	OS のクリーン インストールが必要です。
Windows Server 2003	IIS 6.0	1.0, 1.1, 2.0	Windows Vista にはアップグレードできません。
Windows XP Home	使用不可	1.0, 1.1, 2.0	Windows XP Home には IIS は含まれていません。ユーザーは Windows Vista に IIS 7 を新しくインストールできます。
Windows XP Professional	IIS 5.1	1.0	Windows Vista では、.NET Framework 1.0 はサポートされません。ASP.NET 1.0 アプリケーションを、少なくとも ASP.NET 1.1 (ASP.NET 2.0 を推奨) にアップグレードする必要があります。
		1.1	アップグレード後に、手動構成が必要です (この記事の後半を参照してください)。
		2.0	ASP.NET 2.0 を統合モードで構成するには、アップグレード後に、IIS セットアップ オプションで ASP.NET を選択する必要があります。
Windows XP Tablet PC	IIS 5.1	1.0	Windows Vista では、.NET Framework 1.0 はサポートされません。ASP.NET 1.0 アプリケーションを、少なくとも ASP.NET 1.1 (ASP.NET 2.0 を推奨) にアップグレードする必要があります。
		1.1	アップグレード後に、手動構成が必要です (この記事の後半を参照してください)。
		2.0	ASP.NET 2.0 を統合モードで構成するには、アップグレード後に、IIS セットアップ オプションで ASP.NET を選択する必要があります。
Windows XP Professional x64	IIS 5.1	1.1, 2.0	OS のクリーン インストールが必要です。

インストール後のアプリケーション構成

Windows Vista のインストールまたは Windows Vista へのアップグレードの直後に、アプリケーションが動作するように追加の構成ステップを実行する必要があります。インストール後の構成は、各アプリケーションで使用される ASP.NET バージョンごとに異なります。

ASP.NET 1.1 アプリケーションの構成

.NET Framework 1.1 (ASP.NET 1.1 アプリケーションの実行に必要です) をインストールする前に、以下の 2 つのステップを実行して ASP.NET アプリケーションを有効にする必要があります。

手順

アプリケーションで使用する ASP.NET バージョンに一致する .NET Framework バージョンが使用されるように、ASP.NET アプリケーションを実行する IIS 7 の各アプリケーション プールを明示的に構成する必要があります。各アプリケーション プールはそれぞれ 1 つの ASP.NET バージョンしか実行できないので、ASP.NET バージョンごとに別々のアプリケーション プールを使用する必要があります。

IIS マネージャー コンソールで、[アプリケーション プール] をクリックし、アプリケーション プールの 1 つを右クリックして [基本設定] をクリックします。図 1 に示されている [アプリケーション プールの編集] ダイアログ ボックスで、アプリケーション プールに構成するアプリケーションに一致する .NET Framework バージョンを選択し、[OK] をクリックします。

図 1: アプリケーション プールの編集

  

クラシック モードでの ASP.NET 1.1 の使用

ASP.NET 1.1 をクラシック モードで実行するときは IIS ISAPI 拡張が使用されます。クラシック モードは、インストールまたはアップグレード後の ASP.NET の既定の設定です (ASP.NET 2.0 は、ISAPI 拡張を必要としない Windows Vista 上の統合モードでも実行できることに注意してください)。

IIS 管理コンソールの "ISAPI および CGI の制限" 構成を使用して、実行するアプリケーションで使用する ASP.NET のバージョンを明示的に許可する必要があります。IIS マネージャーを開き、[ISAPI および CGI の制限] を選択します。[ISAPI および CGI の制限] ページで、[制限] 列が [許可しない] に設定されている ASP.NET の各バージョンを選択し、このページの右側の [許可] リンクをクリックして設定を [許可] に変更します。

図 2 に、ASP.NET 1.1 に使用する Aspnet_isapi.dll バージョンの行が選択された状態の [ISAPI および CGI の制限] ページの例を示します。この図の ISAPI 拡張の設定を、[許可しない] から [許可] に変更する必要があります。

図 2: ISAPI および CGI の制限の一覧

ASP.NET 2.0 アプリケーションの構成

Windows Vista のインストール中に .NET Framework 2.0 がインストールされるので、インストール後には既に、サーバーに ASP.NET 2.0 が存在しています。しかし、Vista 上で ASP.NET 2.0 アプリケーション用の ASP.NET 構成を完了するには、以下の 2 つのステップを実行する必要があります。

ステップ 1

Windows Vista のパッケージ マネージャー ([コントロール パネル]、[プログラムと機能]、[Windows の機能の有効化または無効化] の順に選択) で、図 3 に示すように [ASP.NET] をオンにし、[OK] をクリックします。

メモ: このステップの前に、コンピューターに既に ASP.NET がインストールされている場合も、この方法で [ASP.NET] をオンにすることで、追加の構成ステップを確実に完了できます。

図 3: Windows Vista のインストール - Windows の機能

ステップ 2

アプリケーションで使用する ASP.NET バージョンに一致する .NET Framework バージョンが使用されるように、ASP.NET アプリケーションを実行する IIS 7 の各アプリケーション プールを明示的に構成する必要があります。各アプリケーション プールはそれぞれ 1 つの ASP.NET バージョンしか実行できないので、ASP.NET バージョンごとに別々のアプリケーション プールを使用する必要があります。

IIS マネージャーで、[アプリケーション プール] をクリックし、アプリケーション プールの 1 つを右クリックして [基本設定] をクリックします。図 4 に示されている [アプリケーション プールの編集] ダイアログ ボックスで、アプリケーション プールに構成するアプリケーションに一致する .NET Framework バージョンを選択し、[OK] をクリックします。

図 4: アプリケーション プールと統合モード

アプリケーション プールの設定

旧バージョンの Windows オペレーティング システム上の ASP.NET アプリケーションを Windows Vista にアップグレードすると、次のような IIS 7 のアプリケーション分離設定に基づいて、アプリケーションがアプリケーション プールに構成されます。

アップグレード前の IIS 分離構成	IIS 7 アプリケーション プール	IIS 7 アプリケーション プール ID
Low	AppPool Low	NT AUTHORITY\NETWORK SERVICE
Medium	AppPool Medium	IWAM_<コンピューター名>
High	アプリケーションは、アプリケーション名と一致するアプリケーション プールに構成される	IWAM_<コンピューター名>

ASP.NET Version 1.0 は Windows Vista ではサポートされていない

.NET Framework 1.0 は Windows Vista でサポートされないので、ASP.NET 1.0 アプリケーションを少なくとも ASP.NET 1.1 にアップグレードする必要があります。新しいバージョンの ASP.NET の優れたパフォーマンスと保守機能という利点を活用するために、ASP.NET 1.0 アプリケーションを ASP.NET 2.0 にアップグレードすることを強く推奨します。

HTTP ハンドラー

Windows Vista 上の IIS 7 にアップグレードする際に、グローバル レベルで必須の HTTP ハンドラーのみがアップグレードされます。サイト レベルで構成されたハンドラーはアップグレードされません。

共存のサポート

ASP.NET の異なるバージョン (1.1 と 2.0 など) で開発したアプリケーションを、IIS 7 で共存させることができます。そのためには、アプリケーションを IIS アプリケーション プールに構成する必要があります。このプールは、該当アプリケーションの開発に使用した ASP.NET バージョン用に構成する必要があります。アプリケーション プールごとに、ASP.NET の 1 つのバージョンのみを構成できます。

64 ビット Windows Vista で .NET Framework 1.1 を使用するには WoW 64 構成が必要

Windows Vista の 64 ビット バージョンに .NET Framework 1.1 をインストールすると、ASP.NET は正しくセットアップされません。.NET Framework 1.1 を Windows Vista の 64 ビット バージョンにインストールした後に、IIS 管理ツールを使用して、グローバル レベルで WOW 64 を使用して実行されるように、手動でアプリケーションを構成する必要があります。

アプリケーションで使用するパイプライン モードの構成

IIS 7 は、新しいアプリケーションに対して新しい統合モードを使用するように構成されています。これは既定の動作です。アプリケーション プールの設定を使用して、パイプライン モードを構成します。以下のいずれかの方法で、これらの設定を変更します。

• IIS 7 管理ツール

• APPCMD.EXE コマンド ライン ツール

• テキスト エディターを使用してアプリケーション構成ファイルを編集

既存のコンピューターを IIS 7 にアップグレードすると、既定では、それらのアプリケーションはクラシック モードで実行されるように構成されます。クラシック モードは、旧バージョンの IIS の HTTP パイプラインの実装に特定の依存関係を持つアプリケーションに対して、互換性を提供します。

ただし、IIS 7 を実行しているコンピューターに既存のアプリケーションをインポートする場合、および Web サイトをコピーする場合は、アプリケーションが実行されるアプリケーション プールの設定によってパイプライン モードが決定されます。

たとえば、コンピューターにアプリケーションをコピーし、既定のアプリケーション プールで実行されるように構成すると、そのアプリケーションは既定で統合モードに構成されたアプリケーション プール設定を使用して実行されます。アプリケーションのパイプライン モードを変更するには、既定のアプリケーション プールの設定を変更するか、目的の設定を持つ新しいアプリケーション プールを作成する必要があります。

既存のアプリケーションが統合モードを使用するように構成する方法の詳細については、記事「ASP.NET と IIS 7 の統合」のセクション「ASP.NET アプリケーションの IIS 7 統合モードへの移行」を参照してください。このセクションには、アプリケーション構成設定の変更手順が記載されています。

互換性

IIS の旧バージョンに対して開発された ASP.NET パイプライン モジュールを、IIS 7 の統合モードを使用して構成すると、動作上の差異やその他の互換性の問題が発生することがあります。このような問題は、IIS の旧バージョンと、IIS 7 のモジュール設計および統合 HTTP パイプラインとのアーキテクチャ上の違いによって発生します。

この記事の残りのセクションでは、アプリケーションで発生する可能性がある互換性の問題および推奨する回避策について説明します。推奨する回避策の実装が現実的でない場合は、互換性の問題を回避するために、クラシック モードで実行されるようにアプリケーションを構成してください。

統合モードとクラシック モードの既知の相違点

これら 2 つのモードの相違点の一覧を以下に示します。この一覧を注意深くお読みください。

統合モードでは、HttpApplication::Init で発生した例外に対して Application_OnError が呼び出されない

統合モードでは、アプリケーションまたはモジュールの初期化中に発生した例外は Application.Error イベントを使用して傍受できません。

また、Server.ClearError を使用してエラーから回復するアプリケーションは、アプリケーションの初期化中にエラーを消去できません。これは、アプリケーションが初期化中のエラーを無視しないようにするための仕様です。発生したそれぞれの例外に対してエラー情報をログに記録するアプリケーションは、アプリケーションの初期化中に発生したエラーをログに記録できなくなります。ただし、これらのエラーは Web イベントおよび HTTP 応答を使用して報告されます。

初期化中のこのような例外処理の実装を必要とするアプリケーションは、統合モードではなくクラシックモードで実行する必要があります。

統合モードでは、EndRequest での Server.ClearError で例外メッセージを消去できない

統合モードでは、例外が要求処理の初期に発生した場合、EndRequest で Server.ClearError を呼び出しても例外応答は消去されません。EndRequest で例外メッセージを消去するアプリケーションは、その応答から例外出力を削除できません。

EndRequest の最中にこのような例外処理の実装を必要とするアプリケーションは、統合モードではなくクラシックモードで実行する必要があります。

統合モードのアプリケーションは、例外の形式が整えられて応答に書き込まれた後で、EndRequest での応答に書き込むことができる

統合モードでは、例外が発生した後に書き込まれた追加の応答に書き込んで表示することができます。

クラシック モードではできません。要求の最中にエラーが発生し、例外が発生した後でアプリケーションが EndRequest で応答に書き込むと、EndRequest で書き込まれた応答情報が表示されます。これは、未処理の例外が含まれている要求にのみ影響します。

例外の後の応答への書き込みを回避するには、応答に書き込む前にアプリケーションで HttpContext.Error または HttpResponse.StatusCode を確認する必要があります。

統合モードでは、応答が空のときに ASP.NET はコンテンツ タイプを抑制しない

統合モードでは、モジュールによって明示的に設定されている場合、応答が空であっても ASP.NET ハンドラーはコンテンツ タイプ ヘッダーを生成します。アプリケーションによっては、空の応答に対してコンテンツ タイプを生成するものがあります。必要に応じて、コンテンツ タイプ ヘッダーを NULL に設定して、明示的に削除するようにアプリケーションを変更してください。

フォーム認証での Windows ID が異なる

アプリケーションでフォーム認証が使用され、匿名アクセスが許可されている場合、統合モードの ID はクラシック モード ID と次の点で異なります。

• ServerVariables["LOGON_USER"] に値が設定されます。
• Request.LogognUserIdentity は、NT AUTHORITY\INTERNET USER アカウントではなく、NT AUTHORITY\NETWORK SERVICE アカウントの資格情報を使用します。

統合モードでは認証が単一の段階で実行されるので、この動作になっています。これに対して、クラシック モードでは、匿名アクセスを使用して IIS 7 で最初に認証が行われてから、フォーム認証を使用して ASP.NET で認証が行われます。このように、認証の結果は常に単一のユーザー、つまりフォーム認証ユーザーになります。フォーム認証ユーザーの資格情報が IIS 7 と ASP.NET の間で同期されるので、AUTH_USER/LOGON_USER は、これと同じユーザーを返します。

この二次的な影響として、LOGON_USER、HttpRequest.LogonUserIdentity、および偽装は、IIS 7 がクラシック モードを使用して認証する匿名ユーザー資格情報にアクセスできなくなりました。

統合モードでは、既定の Authentication_OnAuthenticate イベントが発生しない

統合モードでは、DefaultAuthenticationModule.Authenticate イベントは発生しなくなりました。クラシック モードでは、認証が行われなかった場合に、このイベントが発行されます。統合モードでは、authentication mode="None" が設定され、かつ DefaultAuthentication.Authenticate に登録されているアプリケーションは、統合モードでこの機能がサポートされないことを示す例外を受け取ります。このパターンに依存する認証スキーマは機能しません。

この変更点の影響を回避するために、統合モードのアプリケーションを代わりに AuthenticateRequest に登録できます。

統合モードでは、RewritePath を呼び出した後で、Request.RawUrl に新しいクエリ文字列が含まれる

統合モードでは、新しいクエリ文字列を持つ URL に対して RewritePath が呼び出された後に、Request.RawUrl プロパティにその新しいクエリ文字列が含められます。クラシック モードでは、このプロパティには古いクエリ文字列が含まれます。

この変更点の影響を回避するには、この古い動作に依存しないようにアプリケーションを書き換えてください。

Passport Network 資格情報認証は Windows Vista でサポートされない

Passport Network 資格情報機能は、Windows Vista および Microsoft Windows Server® 2008 オペレーティング システムから削除されているので、Passport Network 資格情報認証を使用するアプリケーションは、既定では ISAPI または統合モードで動作しません。

PassportAuthentication モジュールは統合パイプラインに含まれない

統合モードの既定では、ASP.NET Passport 認証モジュールはパイプラインから削除されています。アプリケーションでこのモジュールを使用する場合は、パイプラインに追加し直すことができます。前述のように、基礎となる Passport Network 資格情報機能は、Windows Vista および Microsoft Windows Server 2008 から削除されているので、Passport Network 資格情報認証を使用するアプリケーションは、既定では ISAPI または統合モードで動作しません。

クエリ文字列内の、大きい有効なフォーム認証チケット (長さが 4,096 バイト以下) は、IIS 7 によって拒否される

IIS 7 は、フォーム認証、セッション状態、匿名 ID などで使用される、計 4,096 バイトを超える Cookie なしの ASP.NET チケット付きの要求を拒否します。これには、大きなクエリ文字列を使用したバッファ オーバーフロー脆弱性を防ぐというセキュリティ上の理由があります。フォーム認証チケット内にカスタム データを格納するアプリケーションや、非常に長いユーザー名を使用するアプリケーションでは、クエリ文字列が長すぎて要求が拒否されることがあります。

この動作を変更するには、IIS 7 の [要求フィルター] 構成セクションで、最大クエリ文字列サイズを調整します。

統合モードでは、要求の最中に ASP.NET 要求のタイムアウトが複数回適用され、要求の実行時間が長くなる

統合モードでは、パイプラインでの新しい移行のたびに、マネージ要求の実行タイムアウトがリセットされます。つまり、タイムアウトに設定された最大時間を 1 つの段階で超えない限り、要求は "タイムアウト値 x モジュール通知の数" の時間を消費できるということです。

遅延した要求は、ASP.NET モジュールの数やモジュールのマージの程度次第では、中止できなかったり、中止するまでに長い時間かかることがあります。タイムアウトの時間設定の長さを短くして、この動作を回避してください。

トレース設定が Server.Transfer の対象ページに転送されない

統合モードでは、Server.Transfer 操作の対象へのトレース設定の転送はサポートされません。

Httpcontext.Current.Response.Write() メソッドが Application_Onstart() 内で動作しない

統合モードでは、アプリケーションは Application_Onstart() メソッド内で Http.Current.Response.Write() を呼び出すことはできません。

PostAuthenticateRequest より前に HttpRequest.LogonUserIdentity にアクセスすると例外がスローされる

統合モードでは、PostAuthenticateRequest より前に HttpRequest.LogonUserIdentity プロパティにアクセスすると、例外がスローされます。モジュールが、PostAuthenticateRequest より前にこのプロパティにアクセスすると、例外がスローされます。

この動作を回避するには、アプリケーションでこのプロパティにアクセスしないようにするか、PostAuthenticateRequest が完了した後でアクセスするようにします。

統合モードでは、匿名認証が無効にされていると、IIS 7 への最初の未認証の要求を ASP.NET モジュールが受け取る

統合モードでは、匿名認証以外の IIS 7 認証スキームが使用されていると、クライアントからの必要な資格情報が含まれていない最初の要求を、BeginRequest および AuthenticateRequest 段階で ASP.NET モジュールが認識できます。

これに対して、クラシック モードでは、ASP.NET が処理する前に IIS が 401 チャレンジで拒否するので、ASP.NET アプリケーションからはそのような要求は不可視です。

つまり、ASP.NET モジュールは、BeginRequest および AuthenticateRequest 段階で余分な要求を認識することになります。この要求は、Web イベント、および BeginRequest または EndRequest で実行されるカスタム ログに表示されます。

ASP.NET は、PostAuthenticateRequest までクライアント ID を偽装できない

統合モードでは、アプリケーションの web.config または machine.config を使用してアプリケーションでクライアント偽装を有効にしている場合、ASP.NET は PostAuthenticateEvent までクライアントを偽装しません。

また、クライアント偽装が有効な場合、BeginRequest および AuthenticateRequest イベントで実行されるモジュールは、認証されたユーザーの ID ではなくプロセス ID を使用して実行されます。認証されたユーザーが確定されていないので、モジュールがこれらのイベントでリソースにアクセスすることはほとんどなく、問題となりません。

ただし、実際にアクセスする場合、リソースへのアクセスにはプロセス ID が使用されます。

この変更によって、ユーザーの権限が昇格する可能性があるので、クライアント偽装を有効にすると、IIS 7 は例外をスローします。つまり、BeginRequest または AuthenticateRequest イベントでリソースがアクセスされることが確認できた場合、アプリケーションをクラシック モードに移行するか、このエラーをオフにする必要があります。

charset と Content-Type に空の文字列が設定されていると、Content-Type ヘッダーが生成されない

HTTP.sys は、Content-Type に String.Empty が明示的に設定されていると、Content-Type ヘッダーを生成しないようになりました。クライアントが空の Content-Type ヘッダーを持つことに依存するアプリケーションは、この変更点の影響を受ける可能性があります。

統合モードでは、次のモジュールが実行される前に、各モジュールで同期および非同期の両方のイベントが発生する

統合モードでは、サーバーが次のモジュールに移動する前に、各モジュールで同期および非同期の両方のイベントが発生します。

これに対して、クラシック モードでは、すべての非同期モジュール通知が最初に実行されて、その後にすべての同期通知が実行されます。アプリケーションがこの順番に依存していない限り、影響はありません。このドキュメントに別途記載の「統合モードを使用すると、PreSendRequestHeaders および PreSendRequestContent でのモジュールの順番が逆になる」を参照してください。

統合モードでは、カスタム IHttpModule で ClearHeader を呼び出した後で、応答ヘッダーが削除される

統合モードでは、ClearHeaders を呼び出しても、既定のヘッダーが自動的に生成されることはありません。アプリケーションで ClearHeaders を呼び出して、ヘッダーを .aspx ページの既定の状態に戻そうとすると、すべての応答ヘッダーが消去されます。

統合モードでは、Windows 認証とフォーム認証を一緒に使用できない

統合モードでは、"impersonate=true" を設定してフォーム認証を使用することはできず、エラーまたは不正な動作が発生します。

統合モードでは、IIS 7 は (ASP.NET の enableHeaderChecking が false に設定されていても) 常に、応答ヘッダー内の新しい行を拒否する

統合モードでは、応答ヘッダーに \r または \n を含む値を設定しようとすると例外がスローされます。クラシック モードでは、ヘッダーのエンコードがオフの場合、この値は既定でエンコードされて渡されます。セキュリティ上の理由から、アプリケーションが、エンコードされていない新しい行をヘッダーの値に書き込まないようにする必要があります。

各モジュールで PreSendRequestHeaders および PreSendRequestContent イベントが一緒に発生する

統合モードでは、PreSendRequestHeaders イベントと PreSendRequestContent イベントに登録したモジュールに対しては、PreSendRequestHeaders イベントと PreSendRequestContent イベントが一緒に通知されます。

たとえば、モジュール A が PreSendRequestContent に対して実行される前に、PreSendRequestHeaders で最初に実行される モジュール B に依存する場合 (たとえばモジュールB が要求の状態の一部を変更し、モジュール A がその変更に依存する場合など)、アプリケーションが動作しなくなる可能性があります。

統合モードを使用すると、PreSendRequestHeaders および PreSendRequestContent でのモジュールの順番が逆になる

統合モードでは、PreSendRequestHeaders と PreSendRequestContent に登録されたモジュールは、セクションでの並び順とは逆に通知されます。これらのイベントのいずれかで実行される複数のモジュールが構成されているアプリケーションは、イベント順の依存関係を共有している場合に、これらの変更点の影響を受けます。

このような問題を回避するには、セクション内のモジュールの順番を変更するか、アプリケーションをクラシック モードで実行してください。

統合モードでは、スレッドとキューの設定が無視される

統合モードでは、ASP.NET (IIS 7 ではありません) がスレッドの要求を処理します。クラシック モードで使用されていたスレッドやキューのセマンティクスは使用しません。この違いにより、クラシック モードと統合モードでは、アプリケーションのスループットや負荷動作が異なることがあります。

統合モードを使用しているときに構成ファイル エラーが発生すると、IIS (ASP.NET ではありません) がエラー メッセージを生成する

統合モードで実行されるアプリケーションについて、IIS 7 はアプリケーションの構成ファイルを読み取るようになりました。その結果、web.config ファイル内に不正な形式の XML が見つかった場合や、ファイル内に構成エラーが存在する場合は、ASP.NET ではなく IIS が常にエラー メッセージを生成します。

IIS 7 と ASP.NET ではエラーの記述形式が異なるので、アプリケーションが統合モードで実行されている場合と、クラシック モードで実行されている場合では、エラー メッセージの形式が異なります。IIS が生成する構成ファイル エラーの例として "内部サーバー エラー構成エラー: 構成ファイルは整形式の XML ではありません" などがあります。

統合モードでは、ASP.NET アプリケーションは、モジュールの Init 呼び出しの間にパイプライン イベントに登録する必要がある

ASP.NET HTTP パイプラインを使用する ASP.NET アプリケーションは、パイプライン外でアプリケーション イベントに登録できました。しかし、IIS 7 統合モード パイプラインを使用する ASP.NET アプリケーションは、必ず、モジュールの Init() メソッド中にイベントに登録する必要があります。次の例に、Init 内にイベントを登録する方法を示します。

Public void Init(httpApplication context)
{

  Context.AuthenticateRequest += new EventHandler(this.AuthenticateUser);

}

IIS 7 モジュールの作成方法の詳細については、記事「.NET を使用したモジュール開発」を参照してください。

その他のリソース

Windows Vista の IIS 7 へのアップグレードの詳細については、Windows Vista での IIS 7 アプリケーション互換性についての記事「Windows Vista の互換性および機能の要件 (英語)」を参照してください。