ASP.NET Core モジュールと IIS の詳細な構成

[アーティクル]
11/06/2024

Note

これは、この記事の最新バージョンではありません。現在のリリースについては、この記事の .NET 9 バージョンを参照してください。

警告

このバージョンの ASP.NET Core はサポート対象から除外されました。詳細については、 .NET および .NET Core サポートポリシーを参照してください。現在のリリースについては、この記事の .NET 9 バージョンを参照してください。

重要

この情報はリリース前の製品に関する事項であり、正式版がリリースされるまでに大幅に変更される可能性があります。 Microsoft はここに示されている情報について、明示か黙示かを問わず、一切保証しません。

現在のリリースについては、この記事の .NET 9 バージョンを参照してください。

この記事では、ASP.NET Core モジュールと IIS の詳細な構成のオプションとシナリオについて説明します。

スタックサイズを変更する

"インプロセスホスティングモデルを使用している場合にのみ適用されます。 "

マネージドスタックのサイズは、web.config ファイルで stackSize の設定を使用して構成します (バイト単位)。既定のサイズは 1,048,576 バイト (1 MB) です。次の例では、スタックサイズを 2 MB (2,097,152 バイト) に変更します。

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="stackSize" value="2097152" />
  </handlerSettings>
</aspNetCore>

構成でローテーションを禁止する

この disallowRotationOnConfigChange 設定は、グローバル構成を変更してもすべてのサイトがリサイクルされるわけではない、ブルーグリーンシナリオを対象としています。このフラグが true の場合、サイト自体に関連する変更のみがリサイクルされます。たとえば、サイトの web.config が変更された場合や、IIS の観点からサイトのパスに関連する変更がある場合、サイトはリサイクルされます。ただし、applicationHost.config に対する一般的な変更では、アプリはリサイクルされません。次の例では、この設定を true に設定します。

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="disallowRotationOnConfigChange" value="true" />
  </handlerSettings>
</aspNetCore>

この設定は API ApplicationPoolRecycling.DisallowRotationOnConfigChange に対応しています

アプリのリサイクル中に 503 の可能性を減らす

既定では、IIS にリサイクルまたはシャットダウンが通知されてから、ANCM がマネージドサーバーにシャットダウンを開始するよう指示するまでに 1 秒の遅延があります。遅延は、ANCM_shutdownDelay 環境変数または shutdownDelay ハンドラー設定を使用して構成できます。どちらの値もミリ秒単位です。遅延は主に、次の場合のレースの可能性を減らすためです。

IIS は、新しいアプリへの要求のキューを開始していません。
ANCM は、古いアプリに入ってくる新しい要求の拒否を開始します。

この設定は、受信した要求がこの分だけ遅れることを意味するものではありません。この設定は、タイムアウトが発生した後、古いアプリインスタンスがシャットダウンを開始することを示します。 CPU 使用率が高いマシンやマシンの速度が低下する場合は、この値を調整して 503 の可能性を減らす必要があります。

次の例では、遅延を 5 秒に設定します。

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="shutdownDelay" value="5000" />
  </handlerSettings>
</aspNetCore>

プロキシの構成で HTTP プロトコルとペアリングトークンを使用する

アウトプロセスホスティングにのみ適用されます。

ASP.NET Core モジュールと Kestrel の間に作成されるプロキシは、HTTP プロトコルを使います。モジュールと Kestrel の間のトラフィックが、サーバーから離れた場所で傍受される危険はありません。

ペアリングトークンを使用すると、Kestrel によって受信される要求が IIS によってプロキシされたものであり、他のソースからのものでないことを保証できます。ペアリングトークンは、モジュールによって作成されて、環境変数 (ASPNETCORE_TOKEN) に設定されます。ペアリングトークンはまた、プロキシされたすべての要求のヘッダー (MS-ASPNETCORE-TOKEN) にも設定されます。 IIS ミドルウェアは、受信した各要求をチェックし、ペアリングトークンヘッダーの値が環境変数の値と一致することを確認します。トークンの値が一致しない場合、要求はログに記録され、拒否されます。ペアリングトークン環境変数およびモジュールと Kestrel の間のトラフィックには、サーバーから離れた場所からアクセスすることはできません。ペアリングトークンの値がわからなければ、攻撃者は IIS ミドルウェアのチェックをバイパスする要求を送信できません。

IIS 共有構成での ASP.NET Core モジュール

ASP.NET Core モジュールのインストーラーは、TrustedInstaller アカウントのアクセス許可を使って実行します。ローカルシステムアカウントには、IIS 共有構成によって使われる共有パスに対する変更アクセス許可がないため、インストーラーが共有上の applicationHost.config ファイル内のモジュール設定を構成しようとすると、アクセス拒否エラーがスローされます。

IIS がインストールされている同じコンピューターで IIS 共有抗生を使用するとき、OPT_NO_SHARED_CONFIG_CHECK パラメーターを 1 に設定して ASP.NET Core Hosting Bundle インストーラーを実行します。

dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1

共有構成のパスが IIS をインストールしている同じコンピューター上にないときは、次の手順を実行します。

IIS 共有構成を無効にします。
インストーラーを実行します。
更新された applicationHost.config ファイルをファイル共有にエクスポートします。
IIS 共有構成を再び有効にします。

データの保護

ASP.NET Core データ保護スタックは、認証で使用されるミドルウェアを含め、いくつかの ASP.NET Core ミドルウェアによって使用されます。データ保護 API がユーザーのコードから呼び出されない場合でも、配置スクリプトを使用するかユーザーコードで、永続的な暗号化キーストアを作成するようにデータ保護を構成する必要があります。データ保護を構成しない場合、既定でキーはメモリ内に保持され、アプリが再起動すると破棄されます。

データ保護キーリングがメモリに格納されている場合、アプリを再起動すると次のようになります。

すべての cookie ベースの認証トークンは無効になります。
ユーザーは、次回の要求時に再度サインインする必要があります。
キーリングで保護されているデータは、いずれも復号化できなくなります。これには、CSRF トークンと ASP.NET Core MVC TempData cookie が含まれます。

キーリングを保持するために IIS でのデータ保護を構成するには、次のいずれかの方法を使用する必要があります。

データ保護のレジストリキーを作成する

ASP.NET Core アプリで使用されるデータ保護キーは、アプリの外部のレジストリに格納されます。特定のアプリのキーを保持するには、アプリプール用のレジストリキーを作成する必要があります。

非 Web ファーム IIS のスタンドアロンインストールの場合、ASP.NET Core アプリで使用するアプリプールごとに、データ保護の PowerShell スクリプト Provision-AutoGenKeys.ps1 を使用できます。このスクリプトを使用すると、HKLM レジストリに、アプリのアプリプールのワーカープロセスアカウントのみがアクセスできるレジストリキーが作成されます。キーは rest で、DPAPI を使用して、コンピューター全体に適用するキーによって暗号化されます。

Web ファームのシナリオの場合は、UNC パスを使用してデータ保護キーリングを格納するようにアプリを構成できます。既定では、キーは暗号化されません。ネットワーク共有に対するファイルのアクセス許可が、アプリが実行される Windows アカウントに確実に限定されているようにしてください。 rest のキーを保護するために、X509 証明書を使用することができます。ユーザーが証明書をアップロードできるメカニズムを検討します。ユーザーの信頼できる証明書ストアに証明書を配置し、ユーザーのアプリが実行されるすべてのコンピューターで証明書を利用できるようにします。詳細については、「ASP.NET Core データ保護の構成」を参照してください。
ユーザープロファイルを読み込むための IIS アプリケーションプールを構成する

この設定は、アプリプールの [詳細設定] の [プロセスモデル] セクションにあります。 [ユーザープロファイルの読み込み] を True に設定します。 True に設定すると、キーはユーザープロファイルディレクトリに格納され、ユーザーアカウントに固有のキーと共にデータ保護 API を使って保護されます。キーは %LOCALAPPDATA%/ASP.NET/DataProtection-Keys フォルダーに保存されます。

アプリプールの setProfileEnvironment 属性も有効にする必要があります。 setProfileEnvironment の既定値は trueです。一部のシナリオ (たとえば、Windows OS) では、setProfileEnvironment は false に設定されます。キーが期待どおりにユーザープロファイルディレクトリに格納されていない場合:
1. %windir%/system32/inetsrv/config フォルダーに移動します。
2. applicationHost.config ファイルを開きます。
3. <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> 要素を探します。
4. setProfileEnvironment 属性 (その規定値は true です) が存在しないことを確認するか、属性の値を明示的に true に設定します。
ファイルシステムをキーリングストアとして使用する

ファイルシステムをキーリングストアとして使用するようにアプリコードを調整します。 X509 証明書を使用してキーリングを保護し、その証明書が信頼された証明書であることを確認します。証明書が自己署名されている場合は、信頼されたルートストアにその証明書を配置します。

Web ファームで IIS を使用する場合:
- すべてのコンピューターがアクセスできるファイル共有を使用します。
- X509 証明書を各コンピューターに配置します。コードでデータ保護を構成します。
データ保護に対してコンピューター全体のポリシーを設定する

データ保護システムによる、Data Protection API を使用するすべてのアプリに対する、既定でコンピューター全体に適用されるポリシーの設定のサポートは限定的です。詳細については、「ASP.NET Core のデータ保護の概要」を参照してください。

IIS 構成

Windows Server オペレーティングシステム

Web サーバー (IIS) サーバーの役割を有効にし、役割のサービスを設定します。

[管理] メニューから役割と機能の追加ウィザードを使用するか、サーバーマネージャーにあるリンクを使用します。 [サーバーの役割] のステップで、 [Web サーバー (IIS)] チェックボックスをオンにします。
[機能] のステップの後に、 [役割サービスの] のステップで Web サーバー (IIS) を読み込みます。希望する IIS の役割サービスを選択するか、既定の役割サービスをそのまま使用します。

Windows 認証 (任意)
Windows 認証を有効にするには、 [Web サーバー]>[セキュリティ] ノードを展開します。 [Windows 認証] 機能を選択します。詳細については、「Windows 認証 <windowsAuthentication>」および Windows 認証の構成に関するページを参照してください。

Websocket (省略可能)
WebSockets は、ASP.NET Core 1.1 以降でサポートされています。 WebSocket を有効にするには、 [Web サーバー]>[アプリケーション開発] ノードを展開します。 [WebSocket プロトコル] 機能を選択します。詳細については、WebSockets に関するページを参照してください。
[確認] のステップを経て Web サーバーの役割とサービスをインストールします。 Web サーバー (IIS) の役割をインストールした後、サーバーと IIS の再起動は必要ありません。

Windows デスクトップオペレーティングシステム

[IIS 管理コンソール] と [World Wide Web サービス] を有効にします。

[コントロールパネル]>[プログラム]>[プログラムと機能]>[Windows の機能の有効化または無効化] (画面の左側) に移動します。
インターネットインフォメーションサービス (IIS) ノードを開きます。 [Web 管理ツール] ノードを開きます。
[IIS 管理コンソール] チェックボックスをオンにします。
[World Wide Web サービス] チェックボックスをオンにします。
[World Wide Web サービス] の既定の機能をそのまま使用するか、IIS 機能をカスタマイズします。

Windows 認証 (任意)
Windows 認証を有効にするには、 [World Wide Web サービス]>[セキュリティ] ノードを展開します。 [Windows 認証] 機能を選択します。詳細については、「Windows 認証 <windowsAuthentication>」および Windows 認証の構成に関するページを参照してください。

Websocket (省略可能)
WebSockets は、ASP.NET Core 1.1 以降でサポートされています。 WebSocket を有効にするには、 [World Wide Web サービス]>[アプリケーション開発機能] ノードを展開します。 [WebSocket プロトコル] 機能を選択します。詳細については、WebSockets に関するページを参照してください。
IIS のインストールに再起動が必要な場合は、システムを再起動します。

[Windows の機能] で [IIS 管理コンソール] と [World Wide Web サービス] を選択します。

仮想ディレクトリ

ASP.NET Core アプリでは IIS 仮想ディレクトリはサポートされません。アプリはサブアプリケーションとしてホスティングできます。

サブアプリケーション

ASP.NET Core アプリは IIS サブアプリケーション (サブアプリ) としてホスティングできます。サブアプリのパスは、ルートアプリの URL の一部になります。

サブアプリ内にある静的資産のリンクは、MVC および Razor Pages 内で、チルダとスラッシュの表記 (~/) を使用する必要があります。チルダとスラッシュの表記によりタグヘルパーがトリガーされ、作成される相対リンクにサブアプリのパスベースが付加されます。 /subapp_path にあるサブアプリの場合、src="~/image.png" を使ってリンクされる画像は src="/subapp_path/image.png" として作成されます。ルートアプリの静的ファイルミドルウェアでは、静的ファイル要求は処理されません。この要求は、サブアプリの静的ファイルミドルウェアによって処理されます。

Note

Razor コンポーネント (.razor) ではチルダとスラッシュの表記を使用しないでください。詳しくは、Blazor アプリのベースパスのドキュメントをご参照ください。

静的資産の src 属性が絶対パス (たとえば src="/image.png") に設定されている場合、リンクはサブアプリのパスベースなしで作成されます。ルートアプリの静的ファイルミドルウェアでは、ルートアプリの Web ルートから資産を提供しようとしますが、ルートアプリから静的資産を利用できる場合を除いて 404 - Not Found 応答が返されます。

ある ASP.NET Core アプリを別の ASP.NET Core アプリの下でサブアプリとしてホスティングするには:

サブアプリ用のアプリプールを確立します。デスクトップ CLR (.NET CLR) ではなく、.NET Core 用の Core 共通言語ランタイム (CoreCLR) が起動されてワーカープロセスでアプリがホストされるため、 [.NET CLR バージョン] を [マネージドコードなし] に設定します。
ルートサイトを IIS マネージャーに追加し、サブアプリをルートサイトの下のフォルダー内に置きます。
IIS マネージャーでサブアプリのフォルダーを右クリックし、 [アプリケーションへの変換] を選択します。
[アプリケーションの追加] ダイアログボックスで、 [アプリケーションプール] に対して [選択] ボタンを使い、作成したアプリケーションプールをサブアプリ用に割り当てます。 [OK] を選択します。

サブアプリに対して個別のアプリプールを割り当てることは、インプロセスホスティングモデルを使用する場合必須となります。

インプロセスホスティングモデルと ASP.NET Core モジュールの構成の詳細については、「IIS の ASP.NET Core モジュール (ANCM)」を参照してください。

アプリケーションプール

アプリケーションプールの分離は、ホスティングモデルによって決定されます。

インプロセスホスティング: 別のアプリケーションプールでアプリケーションを実行する必要があります。
アウトプロセスホスティング: アプリケーションをそれぞれ専用のアプリケーションプールで実行して、アプリケーションを相互に分離することをお勧めします。

IIS の [Web サイトの追加] ダイアログの既定では、アプリケーションごとに 1 つのアプリケーションプールです。 [サイト名] を指定すると、入力したテキストが自動的に [アプリケーションプール] テキストボックスに設定されます。サイトが追加されるときに、そのサイト名を使用して新しいアプリプールが作成されます。

アプリケーションプール Identity

アプリプール identity アカウントを使用すると、ドメインやローカルアカウントを作成して管理する必要なく、一意のアカウントでアプリを実行できます。 IIS 8.0 以降の IIS 管理者ワーカープロセス (WAS) は、新しいアプリプールの名前で仮想アカウントを作成し、既定によってアプリプールのワーカープロセスをこのアカウントで実行します。 IIS 管理コンソールの、アプリプールに対する [詳細設定] で、確実に Identity で ApplicationPoolIdentity が使用されるように設定します。

アプリケーションプールの [詳細設定] ダイアログ

IIS 管理プロセスは、Windows セキュリティシステムでのアプリプールの名前を使用して、セキュリティで保護された識別子を作成します。この identity を使用してリソースを保護することができます。ただし、この identity は実際のユーザーアカウントではなく、Windows ユーザーの管理コンソールに表示されません。

アプリに対する IIS ワーカープロセスのアクセス許可を昇格させる必要がある場合は、アプリを含むディレクトリのアクセス制御リスト (ACL) を変更します。

エクスプローラーを開き、そのディレクトリに移動します。
そのディレクトリを右クリックし、 [プロパティ] を選択します。
[セキュリティ] タブの [編集] ボタンを選択し、 [追加] ボタンをクリックします。
[場所] ボタンを選択し、システムが選択されていることを確認します。
IIS AppPool\{APP POOL NAME} 領域に、IIS AppPool\{APP POOL NAME} という形式で入力します。プレースホルダー {APP POOL NAME} はアプリプール名です。 [名前の確認] を選択します。 DefaultAppPool で、IIS AppPool\DefaultAppPool を使用して名前を確認します。 [名前の確認] ボタンが選択されているときには、DefaultAppPool の値が、オブジェクト名領域に表示されます。オブジェクト名の領域に直接アプリケーションプール名を入力することはできません。 IIS AppPool\{APP POOL NAME} 形式を使用します。ここで、プレースホルダー {APP POOL NAME} は、オブジェクト名を確認するときのアプリプール名です。
[OK] を選択します。
読み取りと実行のアクセス許可は、既定で付与されるはずです。必要に応じて、追加のアクセス許可を提供します。

ICACLS ツールを使用してコマンドプロンプトでアクセス許可を付与することもできます。 DefaultAppPool を例として使用すると、MyWebApp フォルダー、サブフォルダー、およびファイルへの読み取りと実行のアクセス許可を付与するには、次のコマンドを使用します。

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool:(OI)(CI)RX"

詳細については、「icacls」のトピックを参照してください。

HTTP/2 のサポート

HTTP/2 は、次の IIS 展開シナリオでの ASP.NET Core でサポートされます。

インプロセス
- Windows Server 2016/Windows 10 以降、IIS 10 以降
- TLS 1.2 以降の接続
アウトプロセス
- Windows Server 2016/Windows 10 以降、IIS 10 以降
- 一般向けのエッジサーバー接続では HTTP/2 を使用しますが、Kestrel サーバーへのリバースプロキシ接続では HTTP/1.1 を使用します。
- TLS 1.2 以降の接続

インプロセスの展開の場合、HTTP/2 接続が確立されると、HttpRequest.Protocol によって HTTP/2 が報告されます。アウトプロセスの展開の場合、HTTP/2 接続が確立されると、HttpRequest.Protocol によって HTTP/1.1 が報告されます。

インプロセスホスティングモデルとアウトプロセスホスティングモデルの詳細については、「IIS の ASP.NET Core モジュール (ANCM)」を参照してください。

HTTP/2 は既定で有効になっています。 HTTP/2 接続が確立されない場合、接続は HTTP/1.1 にフォールバックします。 IIS 展開での HTTP/2 構成の詳細については、IIS での HTTP/2 に関するページを参照してください。

CORS プレフライト要求

"このセクションは、.NET Framework をターゲットにした ASP.NET Core アプリにのみ適用されます。 "

.NET Framework をターゲットにした ASP.NET Core アプリの場合、IIS では既定で OPTIONS 要求がアプリに渡されません。 OPTIONS 要求を渡すように web.config でアプリの IIS のハンドラーを構成する方法については、ASP.NET Web API 2 でのクロスオリジン要求の有効化:CORS のしくみに関する記事をご覧ください。

Application Initialization モジュールとアイドルタイムアウト

IIS 内で ASP.NET Core モジュールバージョン 2 によってホストされている場合:

Application Initialization モジュール: アプリのホストされているインプロセスまたはアウトプロセスは、ワーカープロセスの再起動時またはサーバーの再起動時に自動的に起動するように構成できます。
アイドルタイムアウト: アプリのホストされているインプロセスは、非アクティブ期間中にタイムアウトしないように構成できます。

Application Initialization モジュール

"アプリのホストされているインプロセスとアウトプロセスに適用されます。 "

IIS Application Initialization は、アプリプールが開始するときまたはリサイクルされるときに、アプリに HTTP 要求を送信する IIS 機能です。要求によってアプリの起動がトリガーされます。既定では、IIS ではアプリのルート URL (/) に対して要求が発行され、アプリが初期化されます (構成の詳細についてはその他の技術情報を参照)。

IIS Application Initialization 役割の機能が有効になっていることを確認します。

Windows 7 以降のデスクトップシステム上で、IIS をローカルで使う場合:

[コントロールパネル]>[プログラム]>[プログラムと機能]>[Windows の機能の有効化または無効化] (画面の左側) に移動します。
[インターネットインフォメーションサービス]>[World Wide Web サービス]>[アプリケーション開発機能] を開きます。
[Application Initialization] のチェックボックスをオンにします。

Windows Server 2008 R2 以降の場合:

[役割と機能の追加ウィザード] を開きます。
[役割サービスの選択] パネルで、 [アプリケーション開発] ノードを開きます。
[Application Initialization] のチェックボックスをオンにします。

次の方法のいずれかを使って、サイトの Application Initialization モジュールを有効にします。

IIS マネージャーを使う場合:
1. [接続] パネルの [アプリケーションプール] を選択します。
2. 一覧でアプリのアプリプールを右クリックして、 [詳細設定] を選択します。
3. 既定の [開始モード] は OnDemand です。 [開始モード] を AlwaysRunning に設定します。 [OK] を選択します。
4. [接続] パネルの [サイト] ノードを開きます。
5. アプリを右クリックして、[Web サイトの管理]>[詳細設定] の順に選択します。
6. 既定の [有効化されたプリロード] 設定は False です。 [有効化されたプリロード] を True に設定します。 [OK] を選択します。

web.config を使う場合は、doAppInitAfterRestart を true に設定した <applicationInitialization> 要素を、アプリの web.config ファイルの <system.webServer> 要素に追加します。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <applicationInitialization doAppInitAfterRestart="true" />
    </system.webServer>
  </location>
</configuration>

アイドルタイムアウト

"アプリのホストされているインプロセスにのみ適用されます。 "

アプリがアイドル状態にならないようにするには、IIS マネージャーを使ってアプリプールのアイドルタイムアウトを設定します。

[接続] パネルの [アプリケーションプール] を選択します。
一覧でアプリのアプリプールを右クリックして、 [詳細設定] を選択します。
既定の [アイドル状態のタイムアウト (分)] は 20 分です。 [アイドル状態のタイムアウト (分)] を 0 (ゼロ) に設定します。 [OK] を選択します。
ワーカープロセスをリサイクルします。

アプリのホストされているアウトプロセスがタイムアウトにならないようにするには、次の方法のいずれかを使います。

実行させ続けるために、外部サービスからアプリに ping を送信します。
アプリでバックグラウンドサービスのみをホストしている場合は、IIS ホスティングを回避し、ASP.NET Core アプリをホストするための Windows サービスを使います。

Application Initialization モジュールとアイドルタイムアウトに関するその他の技術情報

モジュール、スキーマ、構成ファイルの場所

Module

IIS (x86/amd64) :

%windir%\System32\inetsrv\aspnetcore.dll
%windir%\SysWOW64\inetsrv\aspnetcore.dll
%ProgramFiles%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll
%ProgramFiles(x86)%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll

IIS Express (x86/amd64) :

%ProgramFiles%\IIS Express\aspnetcore.dll
%ProgramFiles(x86)%\IIS Express\aspnetcore.dll
%ProgramFiles%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll
%ProgramFiles(x86)%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll

Schema

IIS

%windir%\System32\inetsrv\config\schema\aspnetcore_schema.xml
%windir%\System32\inetsrv\config\schema\aspnetcore_schema_v2.xml

IIS Express

%ProgramFiles%\IIS Express\config\schema\aspnetcore_schema.xml
%ProgramFiles%\IIS Express\config\schema\aspnetcore_schema_v2.xml

構成

IIS

%windir%\System32\inetsrv\config\applicationHost.config

IIS Express

Visual Studio: {APPLICATION ROOT}\.vs\config\applicationHost.config
iisexpress.exe CLI: %USERPROFILE%\Documents\IISExpress\config\applicationhost.config

ファイルは、applicationHost.config ファイルで aspnetcore を検索することにより見つかります。

Visual Studio で発行する場合の Web 配置のインストール

Web 配置を使用してサーバーにアプリを展開する場合、Web 配置の最新バージョンをサーバーにインストールします。 Web 配置ツールをインストールするには、「IIS ダウンロード: Web 配置ツール」を参照してください。

IIS サイトを作成する

ホストシステムで、アプリの公開フォルダーとファイルを格納するフォルダーを作成します。以下の手順では、フォルダーのパスはアプリへの物理パスとして IIS に提供されます。アプリの配置フォルダーとファイルレイアウトの詳細については、「ASP.NET Core のディレクトリ構造」を参照してください。
IIS マネージャーの [接続] パネルで、サーバーのノードを開きます。 [サイト] フォルダーを右クリックします。コンテキストメニューで [Web サイトの追加] を選択します。
[サイト名] を指定し、 [物理パス] にはアプリの配置フォルダーを設定します。 [バインド] の構成を指定して [OK] を選択し、Web サイトを作成します。

警告

最上位のワイルドカードのバインド ( http://*:80/ と http://+:80 ) は使用しては いけません 。最上位のワイルドカードのバインドは、セキュリティの脆弱性に対してアプリを切り開くことができます。これは、強力と脆弱の両方のワイルドカードに適用されます。ワイルドカードではなく、明示的なホスト名を使用します。全体の親ドメインを制御する場合、サブドメインワイルドカードバインド (たとえば、*.mysub.com) にこのセキュリティリスクはありません (脆弱である *.com とは対照的)。詳細については、RFC 9110: HTTP セマンティクス (セクション 7.2: 「Host and :authority (ホストと :authority)」) に関するページを参照してください。
サーバーのノードでは、 [アプリケーションプール] を選択します。
サイトのアプリケーションプールを右クリックし、コンテキストメニューから [基本設定] を選択します。
[アプリケーションプールの編集] ウィンドウで、 [.NET CLR バージョン] を [マネージドコードなし] に設定します。

ASP.NET Core は、別個のプロセスで実行され、ランタイムを管理します。 ASP.NET Core を使用するためにデスクトップ CLR (.NET CLR) を読み込む必要はありません。 .NET Core 用の Core 共通言語ランタイム (CoreCLR) が起動され、ワーカープロセスでアプリがホストされます。 [.NET CLR バージョン] の [マネージドコードなし] への設定は省略可能ですが、推奨されます。
- インプロセスホスティングモデルを使用する 32 ビット SDK で公開される 32 ビット (x86) の自己完結型展開の場合、32 ビット用のアプリケーションプールを有効にします。 IIS マネージャーで、 [接続] サイドバーの [アプリケーションプール] に移動します。アプリのアプリケーションプールを選択します。 [操作] サイドバーで、[詳細設定] を選択します。 [32 ビットアプリケーションの有効化] を True に設定します。
- インプロセスホスティングモデルを使用する 64 ビット (x64) の自己完結型展開の場合、32 ビット (x86) プロセス用のアプリケーションプールを無効にします。 IIS マネージャーで、 [接続] サイドバーの [アプリケーションプール] に移動します。アプリのアプリケーションプールを選択します。 [操作] サイドバーで、[詳細設定] を選択します。 [32 ビットアプリケーションの有効化] を False に設定します。
プロセスモデル identity に適切なアクセス許可があることを確認します。

アプリプールの既定の identity ([プロセスモデル]>Identity) を ApplicationPoolIdentity から別の identity に変更した場合は、アプリのフォルダー、データベース、その他の必要なリソースにアクセスするために要求されるアクセス許可が新しい identity に設定されていることを確認します。たとえば、アプリケーションプールには、アプリがファイルの読み取りおよび書き込みを行うフォルダーへの読み取りおよび書き込みアクセスが必要です。

Windows 認証の構成 (任意)
詳細については、「Windows 認証を構成する」を参照してください。

シャドウコピー

IIS の ASP.NET Core モジュール (ANCM) にアプリのアセンブリをシャドウコピーすると、app offline file をデプロイしてアプリを停止するよりも優れたエンドユーザーエクスペリエンスを実現することができます。

ASP.NET Core アプリが Windows 上で実行されている場合、バイナリがロックされ、変更や置換ができないようになっています。シャドウコピーでは、アプリのアセンブリのコピーを作成することで、アプリの実行中にアプリのアセンブリを更新できるようにします。

シャドウコピーは、ダウンタイムゼロのデプロイを可能にすることを目的としていないため、IIS がアプリをリサイクルし、一部の要求で 503 Service Unavailable 応答が返されることが予想されます。ダウンタイムゼロでデプロイする場合は、ブルーグリーンデプロイか Azure デプロイスロットのようなパターンを使うことをお勧めします。シャドウコピーはデプロイ時のダウンタイムを最小限に抑えるのに役立ちますが、完全になくすことはできません。

シャドウコピーは web.config の ANCM ハンドラー設定をカスタマイズすることで有効になります。

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore"/>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".logsstdout">
      <handlerSettings>
        <handlerSetting name="enableShadowCopy" value="true" />
        <!-- Ensure that the IIS ApplicationPool identity has permission to this directory -->
        <handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
      </handlerSettings>
    </aspNetCore>
  </system.webServer>
</configuration>

次の方法で共有

ASP.NET Core モジュールと IIS の詳細な構成

スタックサイズを変更する

構成でローテーションを禁止する

アプリのリサイクル中に 503 の可能性を減らす

プロキシの構成で HTTP プロトコルとペアリングトークンを使用する

IIS 共有構成での ASP.NET Core モジュール

データの保護

IIS 構成

仮想ディレクトリ

サブアプリケーション

アプリケーションプール

アプリケーションプール Identity

HTTP/2 のサポート

CORS プレフライト要求

Application Initialization モジュールとアイドルタイムアウト

Application Initialization モジュール

アイドルタイムアウト

Application Initialization モジュールとアイドルタイムアウトに関するその他の技術情報

モジュール、スキーマ、構成ファイルの場所

Module

Schema

構成

Visual Studio で発行する場合の Web 配置のインストール

IIS サイトを作成する

シャドウコピー

その他のリソース

次の方法で共有

ASP.NET Core モジュールと IIS の詳細な構成

スタック サイズを変更する

構成でローテーションを禁止する

アプリのリサイクル中に 503 の可能性を減らす

プロキシの構成で HTTP プロトコルとペアリング トークンを使用する

IIS 共有構成での ASP.NET Core モジュール

データの保護

IIS 構成

仮想ディレクトリ

サブアプリケーション

アプリケーション プール

アプリケーション プール Identity

HTTP/2 のサポート

CORS プレフライト要求

Application Initialization モジュールとアイドル タイムアウト

Application Initialization モジュール

アイドル タイムアウト

Application Initialization モジュールとアイドル タイムアウトに関するその他の技術情報

モジュール、スキーマ、構成ファイルの場所

Module

Schema

構成

Visual Studio で発行する場合の Web 配置のインストール

IIS サイトを作成する

シャドウ コピー

その他のリソース

スタックサイズを変更する

プロキシの構成で HTTP プロトコルとペアリングトークンを使用する

アプリケーションプール

アプリケーションプール Identity

Application Initialization モジュールとアイドルタイムアウト

アイドルタイムアウト

Application Initialization モジュールとアイドルタイムアウトに関するその他の技術情報

シャドウコピー