IIS を使用した Windows での ASP.NET Core のホストHost ASP.NET Core on Windows with IIS

作成者: Luke LathamBy Luke Latham

ASP.NET Core アプリを IIS サーバーに発行する手順のチュートリアルについては、IIS に ASP.NET Core アプリを発行する をご覧ください。For a tutorial experience on publishing an ASP.NET Core app to an IIS server, see IIS に ASP.NET Core アプリを発行する.

.NET Core ホスティング バンドルのインストールInstall the .NET Core Hosting Bundle

サポートされるオペレーティング システムSupported operating systems

次のオペレーティング システムがサポートされています。The following operating systems are supported:

  • Windows 7 以降Windows 7 or later
  • Windows Server 2012 R2 以降Windows Server 2012 R2 or later

HTTP.sys サーバー (旧称 WebListener) は、IIS が含まれるリバース プロキシ構成では動作しません。HTTP.sys server (formerly called WebListener) doesn't work in a reverse proxy configuration with IIS. Kestrel サーバーを使用します。Use the Kestrel server.

Azure でのホスティングの情報については、「Azure App Service に ASP.NET Core アプリを展開する」を参照してください。For information on hosting in Azure, see Azure App Service に ASP.NET Core アプリを展開する.

トラブルシューティング ガイダンスについては、「ASP.NET Core プロジェクトのトラブルシューティングとデバッグ」を参照してください。For troubleshooting guidance, see ASP.NET Core プロジェクトのトラブルシューティングとデバッグ.

サポートされているプラットフォームSupported platforms

32 ビット (x86) または 64 ビット (x64) デプロイ用に発行されるアプリがサポートされています。Apps published for 32-bit (x86) or 64-bit (x64) deployment are supported. アプリが次の条件を満たさない限り、32 ビット (x86) .NET Core SDK を使う 32 ビット アプリをデプロイします:Deploy a 32-bit app with a 32-bit (x86) .NET Core SDK unless the app:

  • 64 ビット アプリ用の大規模な仮想メモリ アドレス空間が必要。Requires the larger virtual memory address space available to a 64-bit app.
  • 大規模な IIS スタック サイズが必要。Requires the larger IIS stack size.
  • 64 ビットのネイティブの依存関係がある。Has 64-bit native dependencies.

64 ビット (x64) .NET Core SDK を使って 64 ビット アプリを発行します。Use a 64-bit (x64) .NET Core SDK to publish a 64-bit app. ホスト システム上に 64 ビット ランタイムが存在している必要があります。A 64-bit runtime must be present on the host system.

ホスティング モデルHosting models

インプロセス ホスティング モデルIn-process hosting model

インプロセス ホスティング モデルを使用する場合、ASP.NET Core アプリはその IIS ワーカー プロセスと同じプロセスで実行されます。Using in-process hosting, an ASP.NET Core app runs in the same process as its IIS worker process. インプロセス ホスティングは、パフォーマンスの点でアウトプロセス ホスティングよりも優れています。要求がループバック アダプター (発信されたネットワーク トラフィックを同じコンピューターに送り返すネットワーク インターフェイス) を介してプロキシされることがないからです。In-process hosting provides improved performance over out-of-process hosting because requests aren't proxied over the loopback adapter, a network interface that returns outgoing network traffic back to the same machine. IIS では Windows プロセス アクティブ化サービス (WAS) を使用してプロセス管理が処理されます。IIS handles process management with the Windows Process Activation Service (WAS).

ASP.NET Core モジュール:The ASP.NET Core Module:

  • アプリの初期化を実行します。Performs app initialization.
    • CoreCLR を読み込みます。Loads the CoreCLR.
    • Program.Main.Calls Program.Main.
  • IIS ネイティブ要求の有効期間を処理します。Handles the lifetime of the IIS native request.

.NET Framework をターゲットにする ASP.NET Core アプリではインプロセス ホスティング モデルはサポートされていません。The in-process hosting model isn't supported for ASP.NET Core apps that target the .NET Framework.

次の図は、IIS (ASP.NET Core モジュール) とインプロセスでホストされるアプリとの間のリレーションシップを示しています。The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted in-process:

インプロセス ホスティング シナリオの ASP.NET Core モジュール

Web からカーネル モードの HTTP.sys ドライバーに要求が届きます。A request arrives from the web to the kernel-mode HTTP.sys driver. このドライバーによって、Web サイトの構成ポート (通常は 80 (HTTP) または 443 (HTTPS)) 上で IIS へのネイティブ要求がルーティングされます。The driver routes the native request to IIS on the website's configured port, usually 80 (HTTP) or 443 (HTTPS). ASP.NET Core モジュールは、ネイティブ要求を受け取り、それを IIS HTTP サーバー (IISHttpServer) に渡します。The ASP.NET Core Module receives the native request and passes it to IIS HTTP Server (IISHttpServer). IIS HTTP サーバーは IIS 用のインプロセス サーバーの実装であり、要求がネイティブからマネージドに変換されます。IIS HTTP Server is an in-process server implementation for IIS that converts the request from native to managed.

IIS HTTP サーバーによって要求が処理された後、その要求は ASP.NET Core ミドルウェア パイプラインにプッシュされます。After the IIS HTTP Server processes the request, the request is pushed into the ASP.NET Core middleware pipeline. ミドルウェア パイプラインは要求を処理し、HttpContext インスタンスとしてアプリのロジックに渡します。The middleware pipeline handles the request and passes it on as an HttpContext instance to the app's logic. アプリの応答は、IIS の HTTP サーバーを経由して IIS に戻されます。The app's response is passed back to IIS through IIS HTTP Server. IIS は、要求を開始したクライアントに応答を送信します。IIS sends the response to the client that initiated the request.

インプロセス ホスティングは既存のアプリではオプトインになっていますが、dotnet new テンプレートは既定ではすべての IIS および IIS Express シナリオにおいてインプロセス ホスティング モデルに設定されています。In-process hosting is opt-in for existing apps, but dotnet new templates default to the in-process hosting model for all IIS and IIS Express scenarios.

CreateDefaultBuilder では、UseIIS メソッドを呼び出し、CoreCLR を起動して IIS ワーカー プロセス (w3wp.exe または iisexpress.exe) 内のアプリをホストすることで、IServer インスタンスを追加します。CreateDefaultBuilder adds an IServer instance by calling the UseIIS method to boot the CoreCLR and host the app inside of the IIS worker process (w3wp.exe or iisexpress.exe). パフォーマンス テストは、.NET Core アプリのインプロセス ホスティングでは、アプリのアウトプロセス ホスティングや Kestrel サーバーへのプロキシ要求に比べ、スループットの要求が大幅に高くなることを示しています。Performance tests indicate that hosting a .NET Core app in-process delivers significantly higher request throughput compared to hosting the app out-of-process and proxying requests to Kestrel server.

注意

単一ファイルの実行可能ファイルとして公開されたアプリは、インプロセス ホスティング モデルで読み込むことができません。Apps published as a single file executable can't be loaded by the in-process hosting model.

アウト プロセス ホスティング モデルOut-of-process hosting model

ASP.NET Core アプリは IIS ワーカー プロセスとは独立したプロセスで実行されるため、プロセス管理は ASP.NET Core モジュールによって処理されます。Because ASP.NET Core apps run in a process separate from the IIS worker process, the ASP.NET Core Module handles process management. モジュールでは、最初の要求が届いたときに ASP.NET Core アプリのプロセスが開始され、プロセスがシャットダウンまたはクラッシュした場合はアプリが再起動されます。The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it shuts down or crashes. この動作は、インプロセスで実行されるアプリであり、WAS (Windows プロセス アクティブ化サービス) によって管理されるアプリと基本的に同じです。This is essentially the same behavior as seen with apps that run in-process that are managed by the Windows Process Activation Service (WAS).

次の図は、IIS (ASP.NET Core モジュール) とアウトプロセスでホストされるアプリとの間のリレーションシップを示しています。The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted out-of-process:

アウト プロセス ホスティングのシナリオの ASP.NET Core モジュール

要求は、Web からカーネル モードの HTTP.sys ドライバーに到着します。Requests arrive from the web to the kernel-mode HTTP.sys driver. ドライバーは、Web サイトの構成ポート (通常は 80 (HTTP) または 443 (HTTPS)) で IIS への要求をルーティングします。The driver routes the requests to IIS on the website's configured port, usually 80 (HTTP) or 443 (HTTPS). モジュールでは、アプリのランダムなポート (ポート 80 または 443 ではありません) で Kestrel に要求が転送されます。The module forwards the requests to Kestrel on a random port for the app, which isn't port 80 or 443.

モジュールによってスタートアップ時に環境変数を介してポートが指定されると、UseIISIntegration 拡張機能によって http://localhost:{PORT} をリッスンするようにサーバーが構成されます。The module specifies the port via an environment variable at startup, and the UseIISIntegration extension configures the server to listen on http://localhost:{PORT}. 追加のチェックが実行され、モジュールから発生していない要求は拒否されます。Additional checks are performed, and requests that don't originate from the module are rejected. モジュールでは HTTPS 転送がサポートされていないため、要求は HTTPS を介して IIS によって受信された場合でも、HTTP を介して転送されます。The module doesn't support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS.

Kestrel によってモジュールから要求が取り込まれた後、その要求は ASP.NET Core ミドルウェア パイプラインにプッシュされます。After Kestrel picks up the request from the module, the request is pushed into the ASP.NET Core middleware pipeline. ミドルウェア パイプラインは要求を処理し、HttpContext インスタンスとしてアプリのロジックに渡します。The middleware pipeline handles the request and passes it on as an HttpContext instance to the app's logic. IIS 統合によって追加されたミドルウェアでは、カーネルへの要求の転送を考慮して、スキーム、リモート IP、およびパスベースが更新されます。Middleware added by IIS Integration updates the scheme, remote IP, and pathbase to account for forwarding the request to Kestrel. アプリの応答が IIS に戻され、IIS はその応答を、要求を開始した HTTP クライアントに返します。The app's response is passed back to IIS, which pushes it back out to the HTTP client that initiated the request.

ASP.NET Core モジュール構成のガイダンスについては、「ASP.NET Core モジュール」を参照してください。For ASP.NET Core Module configuration guidance, see ASP.NET Core モジュール.

ホスティングの詳細については、「Hosting in ASP.NET Core」(ASP.NET Core でのホスティング) を参照してください。For more information on hosting, see Host in ASP.NET Core.

アプリケーション構成Application configuration

IISIntegration コンポーネントを有効にするEnable the IISIntegration components

CreateHostBuilder (Program.cs) でホストを構築する場合は、CreateDefaultBuilder を呼び出して IIS 統合を有効にします。When building a host in CreateHostBuilder (Program.cs), call CreateDefaultBuilder to enable IIS integration:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        ...

CreateDefaultBuilder の詳細については、「.NET での汎用ホスト」を参照してください。For more information on CreateDefaultBuilder, see .NET での汎用ホスト.

IIS のオプションIIS options

インプロセス ホスティング モデルIn-process hosting model

IIS サーバーのオプションを構成するには、IISServerOptions 用のサービス構成を ConfigureServices に含めます。To configure IIS Server options, include a service configuration for IISServerOptions in ConfigureServices. 次の例では、AutomaticAuthentication が無効になります。The following example disables AutomaticAuthentication:

services.Configure<IISServerOptions>(options => 
{
    options.AutomaticAuthentication = false;
});
オプションOption 既定値Default 設定Setting
AutomaticAuthentication true true の場合、IIS サーバーが Windows 認証によって認証された HttpContext.User を設定します。If true, IIS Server sets the HttpContext.User authenticated by Windows Authentication. false の場合、サーバーは HttpContext.User の ID を提供するだけで、AuthenticationScheme によって明示的に要求されたときにチャレンジに応答します。If false, the server only provides an identity for HttpContext.User and responds to challenges when explicitly requested by the AuthenticationScheme. AutomaticAuthentication を機能させるためには、IIS で Windows 認証を有効にする必要があります。Windows Authentication must be enabled in IIS for AutomaticAuthentication to function. 詳細については、Windows 認証に関する記事を参照してください。For more information, see Windows Authentication.
AuthenticationDisplayName null ログイン ページでユーザーに表示名が表示されるように設定します。Sets the display name shown to users on login pages.
AllowSynchronousIO false HttpContext.Request および HttpContext.Response に対して同期 IO が許可されるか。Whether synchronous IO is allowed for the HttpContext.Request and the HttpContext.Response.
MaxRequestBodySize 30000000 HttpRequest の最大要求本文サイズを取得または設定します。Gets or sets the max request body size for the HttpRequest. IIS 自体に、IISServerOptions に設定された MaxRequestBodySize の前に処理される上限 maxAllowedContentLength があることに注意してください。Note that IIS itself has the limit maxAllowedContentLength which will be processed before the MaxRequestBodySize set in the IISServerOptions. MaxRequestBodySize を変更しても、maxAllowedContentLength に影響はありません。Changing the MaxRequestBodySize won't affect the maxAllowedContentLength. maxAllowedContentLengthを引き上げるには、web.config 内にエントリを追加して maxAllowedContentLength をより高い値に設定します。To increase maxAllowedContentLength, add an entry in the web.config to set maxAllowedContentLength to a higher value. 詳細については、「Configuration (構成)」を参照してください。For more details, see Configuration.

アウトプロセス ホスティング モデルOut-of-process hosting model

IIS オプションを構成するには、IISOptions 用のサービス構成を ConfigureServices に含めます。To configure IIS options, include a service configuration for IISOptions in ConfigureServices. 次の例では、アプリが HttpContext.Connection.ClientCertificate を設定できません。The following example prevents the app from populating HttpContext.Connection.ClientCertificate:

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});
オプションOption 既定値Default 設定Setting
AutomaticAuthentication true true の場合、IIS 統合ミドルウェアによって、Windows 認証で認証された HttpContext.User が設定されます。If true, IIS Integration Middleware sets the HttpContext.User authenticated by Windows Authentication. false の場合、ミドルウェアは HttpContext.User の ID を提供するだけで、AuthenticationScheme によって明示的に要求されたときに課題に応答します。If false, the middleware only provides an identity for HttpContext.User and responds to challenges when explicitly requested by the AuthenticationScheme. AutomaticAuthentication を機能させるためには、IIS で Windows 認証を有効にする必要があります。Windows Authentication must be enabled in IIS for AutomaticAuthentication to function. 詳細については、「Windows 認証」のトピックを参照してください。For more information, see the Windows Authentication topic.
AuthenticationDisplayName null ログイン ページでユーザーに表示名が表示されるように設定します。Sets the display name shown to users on login pages.
ForwardClientCertificate true true の場合、MS-ASPNETCORE-CLIENTCERT 要求ヘッダーが指定されていると、HttpContext.Connection.ClientCertificate が設定されます。If true and the MS-ASPNETCORE-CLIENTCERT request header is present, the HttpContext.Connection.ClientCertificate is populated.

プロキシ サーバーとロード バランサーのシナリオProxy server and load balancer scenarios

要求が発生したスキーム (HTTP/HTTPS) とリモート IP アドレスを転送するために、Forwarded Headers Middleware を構成する IIS 統合ミドルウェアと、ASP.NET Core モジュールが構成されます。The IIS Integration Middleware, which configures Forwarded Headers Middleware, and the ASP.NET Core Module are configured to forward the scheme (HTTP/HTTPS) and the remote IP address where the request originated. 追加のプロキシ サーバーとロード バランサーの背後でホストされているアプリでは、追加の構成が必要になる場合があります。Additional configuration might be required for apps hosted behind additional proxy servers and load balancers. 詳細については、「プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する」を参照してください。For more information, see Configure ASP.NET Core to work with proxy servers and load balancers.

web.config ファイルweb.config file

web.config ファイルでは、ASP.NET Core モジュールを設定します。The web.config file configures the ASP.NET Core Module. web.config ファイルの作成、変換、および公開は、プロジェクトの公開時に、MSBuild ターゲット (_TransformWebConfig) によって処理されます。Creating, transforming, and publishing the web.config file is handled by an MSBuild target (_TransformWebConfig) when the project is published. このターゲットは、Web SDK ターゲット (Microsoft.NET.Sdk.Web) に存在します。This target is present in the Web SDK targets (Microsoft.NET.Sdk.Web). SDK は、プロジェクト ファイルの先頭で設定されています。The SDK is set at the top of the project file:

<Project Sdk="Microsoft.NET.Sdk.Web">

プロジェクト内に web.config ファイルが存在しない場合、そのファイルは ASP.NET Core モジュールを構成するための適切な processPatharguments を使用して作成され、発行された出力に移行されます。If a web.config file isn't present in the project, the file is created with the correct processPath and arguments to configure the ASP.NET Core Module and moved to published output.

プロジェクトに web.config ファイルが含まれていない場合、そのファイルは ASP.NET Core モジュールを構成するための正しい processPatharguments を使用して作成され、発行された出力に移行されます。If a web.config file is present in the project, the file is transformed with the correct processPath and arguments to configure the ASP.NET Core Module and moved to published output. 変換によりファイル内の IIS 構成の設定が変わることはありません。The transformation doesn't modify IIS configuration settings in the file.

web.config ファイルは、アクティブな IIS モジュールを制御する追加の IIS 構成設定を提供する可能性があります。The web.config file may provide additional IIS configuration settings that control active IIS modules. ASP.NET Core アプリを使用して要求を処理できる IIS モジュールの詳細については、IIS モジュールのトピックを参照してください。For information on IIS modules that are capable of processing requests with ASP.NET Core apps, see the IIS modules topic.

Web SDK によって web.config ファイルが変換されないようにするため、 <IsTransformWebConfigDisabled> プロパティをプロジェクト ファイルで使用します。To prevent the Web SDK from transforming the web.config file, use the <IsTransformWebConfigDisabled> property in the project file:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Web SDK ファイルの変換を無効にすると、 processPath引数開発者によって手動で設定する必要があります。When disabling the Web SDK from transforming the file, the processPath and arguments should be manually set by the developer. 詳細については、「ASP.NET Core モジュール」を参照してください。For more information, see ASP.NET Core モジュール.

web.config ファイルの場所web.config file location

ASP.NET Core モジュールを正しく設定するためには、web.config ファイルが、展開されるアプリのコンテンツ ルート パス (通常はアプリ ベース パス) に存在する必要があります。In order to set up the ASP.NET Core Module correctly, the web.config file must be present at the content root path (typically the app base path) of the deployed app. これは、IIS に提供される web サイトの物理パスと同じ場所です。This is the same location as the website physical path provided to IIS. Web.config ファイルは、Web 配置を使用して複数のアプリの発行を有効にするため、アプリのルートで必要です。The web.config file is required at the root of the app to enable the publishing of multiple apps using Web Deploy.

アプリの物理パスには、 <assembly>.runtimeconfig.json<assembly>.xml (XML ドキュメントのコメント)、 <assembly>.deps.json などの機密性の高いファイルが存在します。Sensitive files exist on the app's physical path, such as <assembly>.runtimeconfig.json, <assembly>.xml (XML Documentation comments), and <assembly>.deps.json. web.config ファイルが存在し、サイトは通常どおり起動した場合、IIS は、これらの機密性の高いファイルが要求された場合にファイルを提供しません。When the web.config file is present and the site starts normally, IIS doesn't serve these sensitive files if they're requested. web.configファイルが存在しないか、不適切な名前が付けられているか、または通常の起動用にサイトを構成できない場合、IIS が機密性の高いファイルを公開する可能性があります。If the web.config file is missing, incorrectly named, or unable to configure the site for normal startup, IIS may serve sensitive files publicly.

web.configファイルは、展開環境に常に存在し、適切な名前が付けられ、通常の起動用にサイトを構成できる必要があります。web.config ファイルを運用環境の展開から削除しないでください。The web.config file must be present in the deployment at all times, correctly named, and able to configure the site for normal start up. Never remove the web.config file from a production deployment.

web.config を変換するTransform web.config

発行時に web.config を変換する必要がある場合 (たとえば、構成、プロファイル、環境に基づいて環境変数を設定する場合) は、web.config を変換する を参照してください。If you need to transform web.config on publish (for example, set environment variables based on the configuration, profile, or environment), see web.config を変換する.

IIS 構成IIS configuration

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

Web サーバー (IIS) サーバーの役割を有効にし、役割のサービスを設定します。Enable the Web Server (IIS) server role and establish role services.

  1. [管理] メニューから役割と機能の追加ウィザードを使用するか、サーバー マネージャーにあるリンクを使用します。Use the Add Roles and Features wizard from the Manage menu or the link in Server Manager. [サーバーの役割] のステップで、 [Web サーバー (IIS)] チェック ボックスをオンにします。On the Server Roles step, check the box for Web Server (IIS).

    [サーバーの役割の選択] のステップで Web サーバー IIS の役割を選択します。

  2. [機能] のステップの後に、 [役割サービスの] のステップで Web サーバー (IIS) を読み込みます。After the Features step, the Role services step loads for Web Server (IIS). 希望する IIS の役割サービスを選択するか、既定の役割サービスをそのまま使用します。Select the IIS role services desired or accept the default role services provided.

    [役割サービスの選択] のステップで既定の役割サービスを選択します。

    Windows 認証 (任意)Windows Authentication (Optional)
    Windows 認証を有効にするには、 [Web サーバー] > [セキュリティ] ノードを展開します。To enable Windows Authentication, expand the following nodes: Web Server > Security. [Windows 認証] 機能を選択します。Select the Windows Authentication feature. 詳細については、「Windows Authentication <windowsAuthentication>」および「Configure Windows authentication」(Windows 認証の構成) を参照してください。For more information, see Windows Authentication <windowsAuthentication> and Configure Windows authentication.

    Websocket (省略可能)WebSockets (Optional)
    WebSockets は、ASP.NET Core 1.1 以降でサポートされています。WebSockets is supported with ASP.NET Core 1.1 or later. WebSocket を有効にするには、 [Web サーバー] > [アプリケーション開発] ノードを展開します。To enable WebSockets, expand the following nodes: Web Server > Application Development. [WebSocket プロトコル] 機能を選択します。Select the WebSocket Protocol feature. 詳細については、WebSockets に関するページを参照してください。For more information, see WebSockets.

  3. [確認] のステップを経て Web サーバーの役割とサービスをインストールします。Proceed through the Confirmation step to install the web server role and services. Web サーバー (IIS) の役割をインストールした後、サーバーと IIS の再起動は必要ありません。A server/IIS restart isn't required after installing the Web Server (IIS) role.

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

[IIS 管理コンソール][World Wide Web サービス] を有効にします。Enable the IIS Management Console and World Wide Web Services.

  1. [コントロール パネル] > [プログラム] > [プログラムと機能] > [Windows の機能の有効化または無効化] (画面の左側) に移動します。Navigate to Control Panel > Programs > Programs and Features > Turn Windows features on or off (left side of the screen).

  2. インターネット インフォメーション サービス (IIS) ノードを開きます。Open the Internet Information Services node. [Web 管理ツール] ノードを開きます。Open the Web Management Tools node.

  3. [IIS 管理コンソール] チェック ボックスをオンにします。Check the box for IIS Management Console.

  4. [World Wide Web サービス] チェック ボックスをオンにします。Check the box for World Wide Web Services.

  5. [World Wide Web サービス] の既定の機能をそのまま使用するか、IIS 機能をカスタマイズします。Accept the default features for World Wide Web Services or customize the IIS features.

    Windows 認証 (任意)Windows Authentication (Optional)
    Windows 認証を有効にするには、 [World Wide Web サービス] > [セキュリティ] ノードを展開します。To enable Windows Authentication, expand the following nodes: World Wide Web Services > Security. [Windows 認証] 機能を選択します。Select the Windows Authentication feature. 詳細については、「Windows Authentication <windowsAuthentication>」および「Configure Windows authentication」(Windows 認証の構成) を参照してください。For more information, see Windows Authentication <windowsAuthentication> and Configure Windows authentication.

    Websocket (省略可能)WebSockets (Optional)
    WebSockets は、ASP.NET Core 1.1 以降でサポートされています。WebSockets is supported with ASP.NET Core 1.1 or later. WebSocket を有効にするには、 [World Wide Web サービス] > [アプリケーション開発機能] ノードを展開します。To enable WebSockets, expand the following nodes: World Wide Web Services > Application Development Features. [WebSocket プロトコル] 機能を選択します。Select the WebSocket Protocol feature. 詳細については、WebSockets に関するページを参照してください。For more information, see WebSockets.

  6. IIS のインストールに再起動が必要な場合は、システムを再起動します。If the IIS installation requires a restart, restart the system.

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

.NET Core ホスティング バンドルのインストールInstall the .NET Core Hosting Bundle

ホスティング システムに .NET Core ホスティング バンドルをインストールします。Install the .NET Core Hosting Bundle on the hosting system. このバンドルをインストールすることで、.NET Core ランタイム、.NET Core ライブラリ、ASP.NET Core モジュールがインストールされます。The bundle installs the .NET Core Runtime, .NET Core Library, and the ASP.NET Core Module. このモジュールでは、ASP.NET Core アプリが IIS の背後で実行できるようになります。The module allows ASP.NET Core apps to run behind IIS.

重要

ホスティング バンドルが IIS の前にインストールされている場合、バンドルのインストールを修復する必要があります。If the Hosting Bundle is installed before IIS, the bundle installation must be repaired. IIS をインストールした後に、ホスティング バンドル インストーラーをもう一度実行します。Run the Hosting Bundle installer again after installing IIS.

.NET Core の 64 ビット (x64) バージョンをインストールした後、ホスティング バンドルをインストールした場合は、SDK が表示されない可能性があります (.NET Core SDK が検出されない)。If the Hosting Bundle is installed after installing the 64-bit (x64) version of .NET Core, SDKs might appear to be missing (No .NET Core SDKs were detected). この問題を解決するには、ASP.NET Core プロジェクトのトラブルシューティングとデバッグ を参照してください。To resolve the problem, see ASP.NET Core プロジェクトのトラブルシューティングとデバッグ.

直接ダウンロード (現在のバージョン)Direct download (current version)

次のリンクを使用してインストーラーをダウンロードします。Download the installer using the following link:

現在の .NET Core ホスティング バンドルのインストーラー (直接ダウンロード)Current .NET Core Hosting Bundle installer (direct download)

以前のバージョンのインストーラーEarlier versions of the installer

以前のバージョンのインストーラーを入手するには:To obtain an earlier version of the installer:

  1. .NET のダウンロードのアーカイブに移動します。Navigate to the .NET download archives.
  2. [.NET Core] の下で、.NET Core のバージョンを選択します。Under .NET Core, select the .NET Core version.
  3. [Run apps - Runtime](アプリの実行 - ランタイム) 列から、目的の .NET Core ランタイム バージョンの行を探します。In the Run apps - Runtime column, find the row of the .NET Core runtime version desired.
  4. [Runtime & Hosting Bundle](ランタイム & ホスティング バンドル) のリンクを使用してインストーラーをダウンロードします。Download the installer using the Runtime & Hosting Bundle link.

警告

一部のインストーラーには、有効期限 (EOL) に達して Microsoft によるサポートが終了した、リリース バージョンが含まれています。Some installers contain release versions that have reached their end of life (EOL) and are no longer supported by Microsoft. 詳細については、サポート ポリシーをご覧ください。For more information, see the support policy.

ホスティング バンドルをインストールするInstall the Hosting Bundle

  1. サーバーでインストーラーを実行します。Run the installer on the server. 管理者のコマンド シェルからインストーラーを実行する場合、次のパラメーターを使用できます。The following parameters are available when running the installer from an administrator command shell:

    • OPT_NO_ANCM=1 – ASP.NET Core モジュールのインストールをスキップします。OPT_NO_ANCM=1 – Skip installing the ASP.NET Core Module.
    • OPT_NO_RUNTIME=1 – .NET Core ランタイムのインストールをスキップします。OPT_NO_RUNTIME=1 – Skip installing the .NET Core runtime. サーバーが自己完結型の展開 (SCD) のみをホストする場合に使用します。Used when the server only hosts self-contained deployments (SCD).
    • OPT_NO_SHAREDFX=1 – ASP.NET Shared Framework (ASP.NET ランタイム) のインストールをスキップします。OPT_NO_SHAREDFX=1 – Skip installing the ASP.NET Shared Framework (ASP.NET runtime). サーバーが自己完結型の展開 (SCD) のみをホストする場合に使用します。Used when the server only hosts self-contained deployments (SCD).
    • OPT_NO_X86=1 – x86 ランタイムのインストールをスキップします。OPT_NO_X86=1 – Skip installing x86 runtimes. 32 ビット アプリをホストしない場合は、このパラメーターを使用します。Use this parameter when you know that you won't be hosting 32-bit apps. 今後、32 ビットと 64 ビットのアプリ両方をホストする可能性がある場合は、このパラメーターを使用せずに、両方のランタイムをインストールします。If there's any chance that you will host both 32-bit and 64-bit apps in the future, don't use this parameter and install both runtimes.
    • OPT_NO_SHARED_CONFIG_CHECK=1 – 共有構成 (applicationHost.config) が IIS のインストールと同じマシン上にある場合、IIS 共有構成を使うためのチェックを無効にします。OPT_NO_SHARED_CONFIG_CHECK=1 – Disable the check for using an IIS Shared Configuration when the shared configuration (applicationHost.config) is on the same machine as the IIS installation. "ASP.NET Core 2.2 以降の Hosting Bundler インストーラーに対してのみ使用できます。 "Only available for ASP.NET Core 2.2 or later Hosting Bundler installers. 詳細については、「ASP.NET Core モジュール」を参照してください。For more information, see ASP.NET Core モジュール.
  2. システムを再起動するか、コマンドシェルで次のコマンドを実行します。Restart the system or execute the following commands in a command shell:

    net stop was /y
    net start w3svc
    

    IIS を再起動すると、インストーラーによって行われたシステム パスへの変更 (環境変数) が取得されます。Restarting IIS picks up a change to the system PATH, which is an environment variable, made by the installer.

ASP.NET Core の共有フレームワーク パッケージの修正プログラムのリリースでは、ロールフォワード動作は採用されていません。ASP.NET Core doesn't adopt roll-forward behavior for patch releases of shared framework packages. 新しいホスティング バンドルをインストールして共有フレームワークをアップグレードした後、システムを再起動するか、コマンドシェルで次のコマンドを実行します。After upgrading the shared framework by installing a new hosting bundle, restart the system or execute the following commands in a command shell:

net stop was /y
net start w3svc

注意

IIS 共有構成の詳細については、「ASP.NET Core Module with IIS Shared Configuration」 (IIS 共有構成の ASP.NET Core モジュール) を参照してください。For information on IIS Shared Configuration, see ASP.NET Core Module with IIS Shared Configuration.

Visual Studio で発行する場合の Web 配置のインストールInstall Web Deploy when publishing with Visual Studio

Web 配置を使用してサーバーにアプリを展開する場合、Web 配置の最新バージョンをサーバーにインストールします。When deploying apps to servers with Web Deploy, install the latest version of Web Deploy on the server. Web 配置をインストールするには、Web Platform Installer (WebPI) を使用するか、Microsoft ダウンロード センターからインストーラーを取得します。To install Web Deploy, use the Web Platform Installer (WebPI) or obtain an installer directly from the Microsoft Download Center. WebPI を使用することをお勧めします。The preferred method is to use WebPI. WebPI は、スタンドアロンのセットアップとホスティング プロバイダー向けの構成を提供します。WebPI offers a standalone setup and a configuration for hosting providers.

IIS サイトを作成するCreate the IIS site

  1. ホスト システムで、アプリの公開フォルダーとファイルを格納するフォルダーを作成します。On the hosting system, create a folder to contain the app's published folders and files. 以下の手順では、フォルダーのパスはアプリへの物理パスとして IIS に提供されます。In a following step, the folder's path is provided to IIS as the physical path to the app. アプリの配置フォルダーとファイル レイアウトについて詳しくは、ASP.NET Core のディレクトリ構造 をご覧ください。For more information on an app's deployment folder and file layout, see ASP.NET Core のディレクトリ構造.

  2. IIS マネージャーの [接続] パネルで、サーバーのノードを開きます。In IIS Manager, open the server's node in the Connections panel. [サイト] フォルダーを右クリックします。Right-click the Sites folder. コンテキスト メニューで [Web サイトの追加] を選択します。Select Add Website from the contextual menu.

  3. [サイト名] を指定し、 [物理パス] にはアプリの配置フォルダーを設定します。Provide a Site name and set the Physical path to the app's deployment folder. [バインド] の構成を指定して [OK] を選択し、Web サイトを作成します。Provide the Binding configuration and create the website by selecting OK:

    [Web サイトの追加] のステップでサイト名、物理パス、ホスト名を指定します。

    警告

    最上位のワイルドカードのバインド ( http://*:80/http://+:80 ) は使用しては いけませんTop-level wildcard bindings (http://*:80/ and http://+:80) should not be used. 最上位のワイルドカードのバインドは、セキュリティの脆弱性に対してアプリを切り開くことができます。Top-level wildcard bindings can open up your app to security vulnerabilities. これは、強力と脆弱の両方のワイルドカードに適用されます。This applies to both strong and weak wildcards. ワイルドカードではなく、明示的なホスト名を使用します。Use explicit host names rather than wildcards. 全体の親ドメインを制御する場合、サブドメイン ワイルドカード バインド (たとえば、*.mysub.com) にこのセキュリティ リスクはありません (脆弱である *.com とは対照的)。Subdomain wildcard binding (for example, *.mysub.com) doesn't have this security risk if you control the entire parent domain (as opposed to *.com, which is vulnerable). 詳細については、rfc7230 セクション-5.4 を参照してください。See rfc7230 section-5.4 for more information.

  4. サーバーのノードでは、 [アプリケーション プール] を選択します。Under the server's node, select Application Pools.

  5. サイトのアプリケーション プールを右クリックし、コンテキスト メニューから [基本設定] を選択します。Right-click the site's app pool and select Basic Settings from the contextual menu.

  6. [アプリケーション プールの編集] ウィンドウで、 [.NET CLR バージョン][マネージド コードなし] に設定します。In the Edit Application Pool window, set the .NET CLR version to No Managed Code:

    .NET CLR バージョンとして [マネージド コードなし] を設定します。

    ASP.NET Core は、別個のプロセスで実行され、ランタイムを管理します。ASP.NET Core runs in a separate process and manages the runtime. ASP.NET Core はデスクトップ CLR (.NET CLR) の読み込みに依存しません—.NET Core 用の Core 共通言語ランタイム (CoreCLR) が起動され、ワーカー プロセスでアプリがホストされます。ASP.NET Core doesn't rely on loading the desktop CLR (.NET CLR)—the Core Common Language Runtime (CoreCLR) for .NET Core is booted to host the app in the worker process. [.NET CLR バージョン][マネージド コードなし] への設定は省略可能ですが、推奨されます。Setting the .NET CLR version to No Managed Code is optional but recommended.

  7. ASP.NET Core 2.2 以降:インプロセス ホスティング モデルを使用する 64 ビット (x64) の自己完結型展開の場合、32 ビット (x86) プロセス用のアプリケーション プールを無効にします。ASP.NET Core 2.2 or later: For a 64-bit (x64) self-contained deployment that uses the in-process hosting model, disable the app pool for 32-bit (x86) processes.

    IIS マネージャー > [アプリケーション プール][操作] サイドバーで、 [アプリケーション プールの既定値の設定] または [詳細設定] を選択します。In the Actions sidebar of IIS Manager > Application Pools, select Set Application Pool Defaults or Advanced Settings. [32 ビット アプリケーションの有効化] を探し、値を False に設定します。Locate Enable 32-Bit Applications and set the value to False. この設定はアウトプロセス ホスティングで展開されたアプリには影響しません。This setting doesn't affect apps deployed for out-of-process hosting.

  8. プロセス モデル ID に適切なアクセス許可があることを確認します。Confirm the process model identity has the proper permissions.

    アプリ プールの既定の ID ( [プロセス モデル] > [ID] ) を ApplicationPoolIdentity から別の ID に変更した場合は、アプリのフォルダー、データベース、その他の必要なリソースにアクセスするために要求されるアクセス許可が新しい ID に設定されていることを確認します。If the default identity of the app pool (Process Model > Identity) is changed from ApplicationPoolIdentity to another identity, verify that the new identity has the required permissions to access the app's folder, database, and other required resources. たとえば、アプリケーション プールには、アプリがファイルの読み取りおよび書き込みを行うフォルダーへの読み取りおよび書き込みアクセスが必要です。For example, the app pool requires read and write access to folders where the app reads and writes files.

Windows 認証の構成 (任意)Windows Authentication configuration (Optional)
詳細については、「Windows 認証を構成する」を参照してください。For more information, see Configure Windows authentication.

アプリを配置するDeploy the app

IIS サイトを作成する」セクションで確立された IIS の [物理パス] フォルダーにアプリを配置します。Deploy the app to the IIS Physical path folder that was established in the Create the IIS site section. お勧めの配置方法は Web 配置ですが、プロジェクトの publish フォルダーからホスティング システムの配置フォルダーにアプリを移動するためのオプションはいくつか存在します。Web Deploy is the recommended mechanism for deployment, but several options exist for moving the app from the project's publish folder to the hosting system's deployment folder.

Visual Studio からのアプリの展開Web Deploy with Visual Studio

Web 配置に使用する発行プロファイルの作成方法については、「Visual Studio publish profiles for ASP.NET Core app deployment」 (ASP.NET Core アプリ展開用の Visual Studio の発行プロファイル) のトピックを参照してください。See the Visual Studio publish profiles for ASP.NET Core app deployment topic to learn how to create a publish profile for use with Web Deploy. ホスティング プロバイダーから発行プロファイルまたはそれを作成するためのサポートが提供されている場合は、そのプロファイルをダウンロードし、Visual Studio の [発行] ダイアログを使用してインポートします。If the hosting provider provides a Publish Profile or support for creating one, download their profile and import it using the Visual Studio Publish dialog:

[発行] ダイアログ ページ

Visual Studio 外部での Web 配置Web Deploy outside of Visual Studio

Visual Studio の外部で、コマンド ラインから Web 配置を使用することもできます。Web Deploy can also be used outside of Visual Studio from the command line. 詳細については、Web 配置ツールに関するページを参照してください。For more information, see Web Deployment Tool.

Web 配置の代替手段Alternatives to Web Deploy

手動コピー、XcopyRobocopy、または PowerShell など、いくつかあるうちの任意の方法を使って、ホスティング システムにアプリを移動します。Use any of several methods to move the app to the hosting system, such as manual copy, Xcopy, Robocopy, or PowerShell.

IIS への ASP.NET Core の展開の詳細については、「IIS 管理者用の展開リソース」を参照してください。For more information on ASP.NET Core deployment to IIS, see the Deployment resources for IIS administrators section.

Web サイトを閲覧するBrowse the website

ホスティング システムにアプリを配置したら、アプリのパブリック エンドポイントの 1 つに要求を行います。After the app is deployed to the hosting system, make a request to one of the app's public endpoints.

次の例では、サイトは IIS のホスト名www.mysite.comポート 80 でバインドされています。In the following example, the site is bound to an IIS Host name of www.mysite.com on Port 80. http://www.mysite.com に対して要求が行われます。A request is made to http://www.mysite.com:

Microsoft Edge ブラウザーに IIS のスタートアップ ページが読み込まれています。

ロックされた展開ファイルLocked deployment files

アプリが実行中は、展開フォルダー内のファイルがロックされます。Files in the deployment folder are locked when the app is running. 展開中にロックされたファイルを上書きすることはできません。Locked files can't be overwritten during deployment. 展開でロックされているファイルをリリースするには、次のいずれかの方法を使用してアプリ プールを停止します。To release locked files in a deployment, stop the app pool using one of the following approaches:

  • Web 配置を使用し、プロジェクト ファイル内の Microsoft.NET.Sdk.Web を参照して停止します。Use Web Deploy and reference Microsoft.NET.Sdk.Web in the project file. app_offline.htm ファイルは、Web アプリのディレクトリのルートに配置されます。An app_offline.htm file is placed at the root of the web app directory. ファイルが存在する場合、ASP.NET Core モジュールはアプリを正常にシャットダウンし、展開中に app_offline.htm ファイルを提供します。When the file is present, the ASP.NET Core Module gracefully shuts down the app and serves the app_offline.htm file during the deployment. 詳細については、「ASP.NET Core モジュール構成リファレンス」を参照してください。For more information, see the ASP.NET Core Module configuration reference.

  • サーバー上の IIS マネージャーで手動によりアプリ プールを停止します。Manually stop the app pool in the IIS Manager on the server.

  • PowerShell を使用して app_offline.html をドロップします (PowerShell 5 以降が必要)。Use PowerShell to drop app_offline.htm (requires PowerShell 5 or later):

    $pathToApp = 'PATH_TO_APP'
    
    # Stop the AppPool
    New-Item -Path $pathToApp app_offline.htm
    
    # Provide script commands here to deploy the app
    
    # Restart the AppPool
    Remove-Item -Path $pathToApp app_offline.htm
    
    

データの保護Data protection

ASP.NET Core データ保護スタックは、認証で使用されるミドルウェアを含め、いくつかの ASP.NET Core ミドルウェアによって使用されます。The ASP.NET Core Data Protection stack is used by several ASP.NET Core middlewares, including middleware used in authentication. データ保護 API がユーザーのコードから呼び出されない場合でも、配置スクリプトを使用するかユーザー コードで、永続的な暗号化キー ストアを作成するようにデータ保護を構成する必要があります。Even if Data Protection APIs aren't called by user code, data protection should be configured with a deployment script or in user code to create a persistent cryptographic key store. データ保護を構成しない場合、既定でキーはメモリ内に保持され、アプリが再起動すると破棄されます。If data protection isn't configured, the keys are held in memory and discarded when the app restarts.

キーリングがメモリに格納されている場合、アプリを再起動すると次のことが行われます。If the key ring is stored in memory when the app restarts:

  • すべての cookie ベースの認証トークンは無効になります。All cookie-based authentication tokens are invalidated.
  • ユーザーは、次回の要求時に再度サインインする必要があります。Users are required to sign in again on their next request.
  • キーリングで保護されているデータは、いずれも復号化できなくなります。Any data protected with the key ring can no longer be decrypted. これには、CSRF トークンASP.NET Core MVC TempData cookie が含まれます。This may include CSRF tokens and ASP.NET Core MVC TempData cookies.

キーリングを保持するために IIS でのデータ保護を構成するには、次のいずれかの方法を使用する必要があります。To configure data protection under IIS to persist the key ring, use one of the following approaches:

  • データ保護のレジストリ キーを作成するCreate Data Protection Registry Keys

    ASP.NET Core アプリで使用されるデータ保護キーは、アプリ外部のレジストリに格納されます。Data protection keys used by ASP.NET Core apps are stored in the registry external to the apps. 特定のアプリのキーを保持するには、アプリ プール用のレジストリ キーを作成する必要があります。To persist the keys for a given app, create registry keys for the app pool.

    非 Web ファーム IIS のスタンドアロン インストールの場合、ASP.NET Core アプリで使用するアプリ プールごとに、データ保護の PowerShell スクリプト Provision-AutoGenKeys.ps1 を使用できます。For standalone, non-webfarm IIS installations, the Data Protection Provision-AutoGenKeys.ps1 PowerShell script can be used for each app pool used with an ASP.NET Core app. このスクリプトは、HKLM レジストリにレジストリ キーを作成します。そのキーは、アプリのアプリ プールのワーカー プロセス アカウントのみがアクセスできます。This script creates a registry key in the HKLM registry that's accessible only to the worker process account of the app's app pool. キーは保存時に、DPAPI を使用して、コンピューター全体に適用するキーによって暗号化されます。Keys are encrypted at rest using DPAPI with a machine-wide key.

    Web ファームのシナリオでは、UNC パスを使用してデータ保護キー リングを格納するようにアプリを構成できます。In web farm scenarios, an app can be configured to use a UNC path to store its data protection key ring. 既定では、データ保護キーは暗号化されません。By default, the data protection keys aren't encrypted. ネットワーク共有のファイルのアクセス許可が、アプリを実行する Windows アカウントに限定されていることを確認します。Ensure that the file permissions for the network share are limited to the Windows account the app runs under. 保存時のキーを保護するために、X509 証明書を使用することができます。An X509 certificate can be used to protect keys at rest. ユーザーが証明書をアップロードできるメカニズムを検討している場合、ユーザーの信頼できる証明書ストアに証明書を配置し、ユーザーのアプリが実行されるすべてのコンピューターで証明書を利用できるようにします。Consider a mechanism to allow users to upload certificates: Place certificates into the user's trusted certificate store and ensure they're available on all machines where the user's app runs. 詳細については、「ASP.NET Core データ保護の構成」を参照してください。See Configure ASP.NET Core Data Protection for details.

  • ユーザー プロファイルを読み込むための IIS アプリケーション プールを構成するConfigure the IIS Application Pool to load the user profile

    この設定は、アプリ プールの [詳細設定][プロセス モデル] セクションにあります。This setting is in the Process Model section under the Advanced Settings for the app pool. [ユーザー プロファイルの読み込み]True に設定します。Set Load User Profile to True. True に設定すると、キーはユーザー プロファイル ディレクトリに格納され、ユーザー アカウントに固有のキーと共にデータ保護 API を使って保護されます。When set to True, keys are stored in the user profile directory and protected using DPAPI with a key specific to the user account. キーは %LOCALAPPDATA%/ASP.NET/DataProtection-Keys フォルダーに保存されます。Keys are persisted to the %LOCALAPPDATA%/ASP.NET/DataProtection-Keys folder.

    アプリ プールの setProfileEnvironment 属性も有効にする必要があります。The app pool's setProfileEnvironment attribute must also be enabled. setProfileEnvironment の既定値は trueです。The default value of setProfileEnvironment is true. 一部のシナリオ (たとえば、Windows OS) では、setProfileEnvironmentfalse に設定されます。In some scenarios (for example, Windows OS), setProfileEnvironment is set to false. キーが期待どおりにユーザー プロファイル ディレクトリに格納されていない場合:If keys aren't stored in the user profile directory as expected:

    1. %windir%/system32/inetsrv/config フォルダーに移動します。Navigate to the %windir%/system32/inetsrv/config folder.
    2. applicationHost.config ファイルを開きます。Open the applicationHost.config file.
    3. <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> 要素を探します。Locate the <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> element.
    4. setProfileEnvironment 属性 (その規定値は true です) が存在しないことを確認するか、属性の値を明示的に true に設定します。Confirm that the setProfileEnvironment attribute isn't present, which defaults the value to true, or explicitly set the attribute's value to true.
  • ファイル システムをキー リング ストアとして使用するUse the file system as a key ring store

    ファイル システムをキー リング ストアとして使用するようにアプリ コードを調整します。Adjust the app code to use the file system as a key ring store. X509 証明書を使用してキー リングを保護し、その証明書が信頼された証明書であることを確認します。Use an X509 certificate to protect the key ring and ensure the certificate is a trusted certificate. 証明書が自己署名されている場合は、信頼されたルート ストアにその証明書を配置します。If the certificate is self-signed, place the certificate in the Trusted Root store.

    Web ファームで IIS を使用する場合:When using IIS in a web farm:

    • すべてのコンピューターがアクセスできるファイル共有を使用します。Use a file share that all machines can access.
    • X509 証明書を各コンピューターに配置します。Deploy an X509 certificate to each machine. コード内にデータ保護を構成します。Configure data protection in code.
  • コンピューター全体に適用するデータ保護ポリシーを設定するSet a machine-wide policy for data protection

    データ保護システムでは、データ保護 API を使用するすべてのアプリに対して、コンピューター全体に適用する既定のポリシーを設定するためのサポートは限定的です。The data protection system has limited support for setting a default machine-wide policy for all apps that consume the Data Protection APIs. 詳細については、「ASP.NET Core データ保護」を参照してください。For more information, see ASP.NET Core データ保護.

仮想ディレクトリVirtual Directories

ASP.NET Core アプリでは IIS 仮想ディレクトリはサポートされません。IIS Virtual Directories aren't supported with ASP.NET Core apps. アプリはサブアプリケーションとしてホスティングできます。An app can be hosted as a sub-application.

サブアプリケーションSub-applications

ASP.NET Core アプリは IIS サブアプリケーション (サブアプリ) としてホスティングできます。An ASP.NET Core app can be hosted as an IIS sub-application (sub-app). サブアプリのパスは、ルート アプリの URL の一部になります。The sub-app's path becomes part of the root app's URL.

サブアプリ内にある静的資産のリンクでは、チルダとスラッシュの表記 (~/) を使う必要があります。Static asset links within the sub-app should use tilde-slash (~/) notation. チルダとスラッシュの表記によりタグ ヘルパーがトリガーされ、作成される相対リンクにサブアプリのパスベースが付加されます。Tilde-slash notation triggers a Tag Helper to prepend the sub-app's pathbase to the rendered relative link. /subapp_path にあるサブアプリの場合、src="~/image.png" を使ってリンクされる画像は src="/subapp_path/image.png" として作成されます。For a sub-app at /subapp_path, an image linked with src="~/image.png" is rendered as src="/subapp_path/image.png". ルート アプリの静的ファイル ミドルウェアでは、静的ファイル要求は処理されません。The root app's Static File Middleware doesn't process the static file request. この要求は、サブアプリの静的ファイル ミドルウェアによって処理されます。The request is processed by the sub-app's Static File Middleware.

静的資産の src 属性が絶対パス (たとえば src="/image.png") に設定されている場合、リンクはサブアプリのパスベースなしで作成されます。If a static asset's src attribute is set to an absolute path (for example, src="/image.png"), the link is rendered without the sub-app's pathbase. ルート アプリの静的ファイル ミドルウェアでは、ルート アプリの Web ルートから資産を提供しようとしますが、ルート アプリから静的資産を利用できる場合を除いて 404 - Not Found 応答が返されます。The root app's Static File Middleware attempts to serve the asset from the root app's web root, which results in a 404 - Not Found response unless the static asset is available from the root app.

ある ASP.NET Core アプリを別の ASP.NET Core アプリの下でサブアプリとしてホスティングするには:To host an ASP.NET Core app as a sub-app under another ASP.NET Core app:

  1. サブアプリ用のアプリ プールを確立します。Establish an app pool for the sub-app. デスクトップ CLR (.NET CLR) ではなく、.NET Core 用の Core 共通言語ランタイム (CoreCLR) が起動されてワーカー プロセスでアプリがホストされるため、 [.NET CLR バージョン][マネージド コードなし] に設定します。Set the .NET CLR Version to No Managed Code because the Core Common Language Runtime (CoreCLR) for .NET Core is booted to host the app in the worker process, not the desktop CLR (.NET CLR).

  2. ルート サイトを IIS マネージャーに追加し、サブアプリをルート サイトの下のフォルダー内に置きます。Add the root site in IIS Manager with the sub-app in a folder under the root site.

  3. IIS マネージャーでサブアプリのフォルダーを右クリックし、 [アプリケーションへの変換] を選択します。Right-click the sub-app folder in IIS Manager and select Convert to Application.

  4. [アプリケーションの追加] ダイアログ ボックスで、 [アプリケーション プール] に対して [選択] ボタンを使い、作成したアプリケーション プールをサブアプリ用に割り当てます。In the Add Application dialog, use the Select button for the Application Pool to assign the app pool that you created for the sub-app. [OK] を選択します。Select OK.

サブアプリに対して個別のアプリ プールを割り当てることは、インプロセス ホスティング モデルを使用する場合必須となります。The assignment of a separate app pool to the sub-app is a requirement when using the in-process hosting model.

インプロセス ホスティング モデルと ASP.NET Core モジュールの構成について詳しくは、ASP.NET Core モジュール をご覧ください。For more information on the in-process hosting model and configuring the ASP.NET Core Module, see ASP.NET Core モジュール.

web.config による IIS の構成Configuration of IIS with web.config

IIS の構成は ASP.NET Core モジュールを使用した ASP.NET Core アプリで機能する IIS シナリオの web.config<system.webServer> セクションによる影響を受けます。IIS configuration is influenced by the <system.webServer> section of web.config for IIS scenarios that are functional for ASP.NET Core apps with the ASP.NET Core Module. たとえば、IIS の構成は動的な圧縮で機能します。For example, IIS configuration is functional for dynamic compression. IIS が動的な圧縮を使用するようにサーバー レベルで構成されている場合、アプリの web.config ファイルの <urlCompression> 要素を使用すると、それを ASP.NET Core アプリに対して無効にすることができます。If IIS is configured at the server level to use dynamic compression, the <urlCompression> element in the app's web.config file can disable it for an ASP.NET Core app.

詳細については、次のトピックを参照してください。For more information, see the following topics:

分離されたアプリ プール (IIS 10.0 以降でサポートされています) で実行する個別アプリに対して環境変数を設定するには、IIS のリファレンス ドキュメントで、環境変数<environmentVariables> のトピックにある AppCmd.exe コマンドのセクションを参照してください。To set environment variables for individual apps running in isolated app pools (supported for IIS 10.0 or later), see the AppCmd.exe command section of the Environment Variables <environmentVariables> topic in the IIS reference documentation.

web.config の構成のセクションConfiguration sections of web.config

web.config の ASP.NET 4.x アプリの構成セクションは、ASP.NET Core アプリの構成では使用されません。Configuration sections of ASP.NET 4.x apps in web.config aren't used by ASP.NET Core apps for configuration:

  • <system.web>
  • <appSettings>
  • <connectionStrings>
  • <location>

ASP.NET Core アプリは、他の構成プロバイダーを使用して構成されます。ASP.NET Core apps are configured using other configuration providers. 詳細については、構成に関するページを参照してください。For more information, see Configuration.

アプリケーション プールApplication Pools

アプリケーション プールの分離は、ホスティング モデルによって決定されます。App pool isolation is determined by the hosting model:

  • インプロセス ホスティング – 別のアプリケーション プールでアプリケーションを実行する必要があります。In-process hosting – Apps are required to run in separate app pools.
  • アウトプロセス ホスティング – アプリケーションをそれぞれ専用のアプリケーションプールで実行して、アプリケーションを相互に分離することをお勧めします。Out-of-process hosting – We recommend isolating the apps from each other by running each app in its own app pool.

IIS の [Web サイトの追加] ダイアログの既定では、アプリケーションごとに 1 つのアプリケーション プールです。The IIS Add Website dialog defaults to a single app pool per app. [サイト名] を指定すると、入力したテキストが自動的に [アプリケーション プール] テキストボックスに設定されます。When a Site name is provided, the text is automatically transferred to the Application pool textbox. サイトが追加されるときに、そのサイト名を使用して新しいアプリ プールが作成されます。A new app pool is created using the site name when the site is added.

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

アプリ プール ID アカウントを使用すると、ドメインやローカル アカウントを作成して管理する必要なく、一意のアカウントでアプリを実行できます。An app pool identity account allows an app to run under a unique account without having to create and manage domains or local accounts. IIS 8.0 以降の IIS 管理者ワーカー プロセス (WAS) は、新しいアプリ プールの名前で仮想アカウントを作成し、既定によってアプリ プールのワーカー プロセスをこのアカウントで実行します。On IIS 8.0 or later, the IIS Admin Worker Process (WAS) creates a virtual account with the name of the new app pool and runs the app pool's worker processes under this account by default. IIS 管理コンソールにあるアプリ プールの [詳細設定] で、IDApplicationPoolIdentity を使用するように設定されていることを確認します。In the IIS Management Console under Advanced Settings for the app pool, ensure that the Identity is set to use ApplicationPoolIdentity:

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

IIS 管理プロセスは、Windows セキュリティ システムでのアプリ プールの名前を使用して、セキュリティで保護された識別子を作成します。The IIS management process creates a secure identifier with the name of the app pool in the Windows Security System. この ID を使用してリソースを保護することができます。Resources can be secured using this identity. ただし、この ID は実際のユーザー アカウントではなく、Windows ユーザーの管理コンソールに表示されません。However, this identity isn't a real user account and doesn't show up in the Windows User Management Console.

アプリに対する IIS ワーカー プロセスのアクセス許可を昇格させる必要がある場合は、アプリを含むディレクトリのアクセス制御リスト (ACL) を変更します。If the IIS worker process requires elevated access to the app, modify the Access Control List (ACL) for the directory containing the app:

  1. エクスプローラーを開き、そのディレクトリに移動します。Open Windows Explorer and navigate to the directory.

  2. そのディレクトリを右クリックし、 [プロパティ] を選択します。Right-click on the directory and select Properties.

  3. [セキュリティ] タブの [編集] ボタンを選択し、 [追加] ボタンをクリックします。Under the Security tab, select the Edit button and then the Add button.

  4. [場所] ボタンを選択し、システムが選択されていることを確認します。Select the Locations button and make sure the system is selected.

  5. [選択するオブジェクト名を入力してください] 領域に、「IIS AppPool\<app_pool_name> 」と入力します。Enter IIS AppPool\<app_pool_name> in Enter the object names to select area. [名前の確認] を選択します。Select the Check Names button. DefaultAppPool で、IIS AppPool\DefaultAppPool を使用して名前を確認します。For the DefaultAppPool check the names using IIS AppPool\DefaultAppPool. [名前の確認] ボタンが選択されているときには、DefaultAppPool の値が、オブジェクト名領域に表示されます。When the Check Names button is selected, a value of DefaultAppPool is indicated in the object names area. オブジェクト名の領域に直接アプリケーション プール名を入力することはできません。It isn't possible to enter the app pool name directly into the object names area. オブジェクト名を確認するときには、IIS AppPool\<app_pool_name> の形式を使用します。Use the IIS AppPool\<app_pool_name> format when checking for the object name.

    アプリ フォルダーのユーザーまたはグループのダイアログを選択します。[名前の確認] を選択する前に、オブジェクト名領域で "DefaultAppPool" のアプリ プール名が "IIS AppPool" に適用されます。

  6. [OK] を選択します。Select OK.

    アプリ フォルダーのユーザーまたはグループのダイアログを選択します。[名前の確認] を選択した後に、オブジェクト名 "DefaultAppPool" がオブジェクト名領域に表示されます。

  7. 読み取り & 実行アクセス許可は、既定で付与される必要があります。Read & execute permissions should be granted by default. 必要に応じて、追加のアクセス許可を提供します。Provide additional permissions as needed.

ICACLS ツールを使用してコマンド プロンプトでアクセス許可を付与することもできます。Access can also be granted at a command prompt using the ICACLS tool. たとえば、DefaultAppPool を使用する場合、次のコマンドを使用します。Using the DefaultAppPool as an example, the following command is used:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

詳細については、「icacls」のトピックを参照してください。For more information, see the icacls topic.

HTTP/2 のサポートHTTP/2 support

HTTP/2 は、次の IIS 展開シナリオでの ASP.NET Core でサポートされます。HTTP/2 is supported with ASP.NET Core in the following IIS deployment scenarios:

  • インプロセスIn-process
    • Windows Server 2016/Windows 10 以降、IIS 10 以降Windows Server 2016/Windows 10 or later; IIS 10 or later
    • TLS 1.2 以降の接続TLS 1.2 or later connection
  • アウトプロセスOut-of-process
    • Windows Server 2016/Windows 10 以降、IIS 10 以降Windows Server 2016/Windows 10 or later; IIS 10 or later
    • 一般向けのエッジ サーバーでは HTTP/2 を使用しますが、Kestrel サーバーへのリバース プロキシ接続では HTTP/1.1 を使用します。Public-facing edge server connections use HTTP/2, but the reverse proxy connection to the Kestrel server uses HTTP/1.1.
    • TLS 1.2 以降の接続TLS 1.2 or later connection

インプロセスの展開の場合、HTTP/2 接続が確立されると、HttpRequest.Protocol によって HTTP/2 が報告されます。For an in-process deployment when an HTTP/2 connection is established, HttpRequest.Protocol reports HTTP/2. アウトプロセスの展開の場合、HTTP/2 接続が確立されると、HttpRequest.Protocol によって HTTP/1.1 が報告されます。For an out-of-process deployment when an HTTP/2 connection is established, HttpRequest.Protocol reports HTTP/1.1.

インプロセスおよびアウトプロセス ホスティング モデルの詳細については、ASP.NET Core モジュール をご覧ください。For more information on the in-process and out-of-process hosting models, see ASP.NET Core モジュール.

HTTP/2 は既定で有効になっています。HTTP/2 is enabled by default. HTTP/2 接続が確立されない場合、接続は HTTP/1.1 にフォールバックします。Connections fall back to HTTP/1.1 if an HTTP/2 connection isn't established. IIS 展開での HTTP/2 構成の詳細については、IIS での HTTP/2 に関するページを参照してください。For more information on HTTP/2 configuration with IIS deployments, see HTTP/2 on IIS.

CORS プレフライト要求CORS preflight requests

"このセクションは、.NET Framework をターゲットにした ASP.NET Core アプリにのみ適用されます。 "This section only applies to ASP.NET Core apps that target the .NET Framework.

.NET Framework をターゲットにした ASP.NET Core アプリの場合、IIS では既定で OPTIONS 要求がアプリに渡されません。For an ASP.NET Core app that targets the .NET Framework, OPTIONS requests aren't passed to the app by default in IIS. OPTIONS 要求を渡すように web.config でアプリの IIS のハンドラーを構成する方法については、ASP.NET Web API 2 でのクロスオリジン要求の有効化:CORS のしくみに関する記事をご覧ください。To learn how to configure the app's IIS handlers in web.config to pass OPTIONS requests, see Enable cross-origin requests in ASP.NET Web API 2: How CORS Works.

Application Initialization モジュールとアイドル タイムアウトApplication Initialization Module and Idle Timeout

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

Application Initialization モジュールApplication Initialization Module

"アプリのホストされているインプロセスとアウトプロセスに適用されます。 "Applies to apps hosted in-process and out-of-process.

IIS Application Initialization は、アプリ プールが開始するときまたはリサイクルされるときに、アプリに HTTP 要求を送信する IIS 機能です。IIS Application Initialization is an IIS feature that sends an HTTP request to the app when the app pool starts or is recycled. 要求によってアプリの起動がトリガーされます。The request triggers the app to start. 既定では、IIS ではアプリのルート URL (/) に対して要求が発行され、アプリが初期化されます (構成の詳細についてはその他の技術情報を参照)。By default, IIS issues a request to the app's root URL (/) to initialize the app (see the additional resources for more details on configuration).

IIS Application Initialization 役割の機能が有効になっていることを確認します。Confirm that the IIS Application Initialization role feature in enabled:

Windows 7 以降のデスクトップ システム上で、IIS をローカルで使う場合:On Windows 7 or later desktop systems when using IIS locally:

  1. [コントロール パネル] > [プログラム] > [プログラムと機能] > [Windows の機能の有効化または無効化] (画面の左側) に移動します。Navigate to Control Panel > Programs > Programs and Features > Turn Windows features on or off (left side of the screen).
  2. [インターネット インフォメーション サービス] > [World Wide Web サービス] > [アプリケーション開発機能] を開きます。Open Internet Information Services > World Wide Web Services > Application Development Features.
  3. [Application Initialization] のチェック ボックスをオンにします。Select the check box for Application Initialization.

Windows Server 2008 R2 以降の場合:On Windows Server 2008 R2 or later:

  1. [役割と機能の追加ウィザード] を開きます。Open the Add Roles and Features Wizard.
  2. [役割サービスの選択] パネルで、 [アプリケーション開発] ノードを開きます。In the Select role services panel, open the Application Development node.
  3. [Application Initialization] のチェック ボックスをオンにします。Select the check box for Application Initialization.

次の方法のいずれかを使って、サイトの Application Initialization モジュールを有効にします。Use either of the following approaches to enable the Application Initialization Module for the site:

  • IIS マネージャーを使う場合:Using IIS Manager:

    1. [接続] パネルの [アプリケーション プール] を選択します。Select Application Pools in the Connections panel.
    2. 一覧でアプリのアプリ プールを右クリックして、 [詳細設定] を選択します。Right-click the app's app pool in the list and select Advanced Settings.
    3. 既定の [開始モード][オンデマンド] です。The default Start Mode is OnDemand. [開始モード][常時実行] に設定します。Set the Start Mode to AlwaysRunning. [OK] を選択します。Select OK.
    4. [接続] パネルの [サイト] ノードを開きます。Open the Sites node in the Connections panel.
    5. アプリを右クリックして、 [Web サイトの管理] > [詳細設定] の順に選択します。Right-click the app and select Manage Website > Advanced Settings.
    6. 既定の [有効化されたプリロード] 設定は [False] です。The default Preload Enabled setting is False. [有効化されたプリロード]True に設定します。Set Preload Enabled to True. [OK] を選択します。Select OK.
  • web.config を使う場合、doAppInitAfterRestarttrue に設定した <applicationInitialization> 要素を、アプリの web.config ファイル内の <system.webServer> 要素に追加します。Using web.config, add the <applicationInitialization> element with doAppInitAfterRestart set to true to the <system.webServer> elements in the app's web.config file:

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

アイドル タイムアウトIdle Timeout

"アプリのホストされているインプロセスにのみ適用されます。 "Only applies to apps hosted in-process.

アプリがアイドル状態にならないようにするには、IIS マネージャーを使ってアプリ プールのアイドル タイムアウトを設定します。To prevent the app from idling, set the app pool's idle timeout using IIS Manager:

  1. [接続] パネルの [アプリケーション プール] を選択します。Select Application Pools in the Connections panel.
  2. 一覧でアプリのアプリ プールを右クリックして、 [詳細設定] を選択します。Right-click the app's app pool in the list and select Advanced Settings.
  3. 既定の [アイドル状態のタイムアウト (分)][20] 分です。The default Idle Time-out (minutes) is 20 minutes. [アイドル状態のタイムアウト (分)][0] (ゼロ) に設定します。Set the Idle Time-out (minutes) to 0 (zero). [OK] を選択します。Select OK.
  4. ワーカー プロセスをリサイクルします。Recycle the worker process.

アプリのホストされているアウトプロセスがタイムアウトにならないようにするには、次の方法のいずれかを使います。To prevent apps hosted out-of-process from timing out, use either of the following approaches:

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

IIS 管理者用の展開リソースDeployment resources for IIS administrators

その他の技術情報Additional resources

ASP.NET Core アプリを IIS サーバーに発行する手順のチュートリアルについては、IIS に ASP.NET Core アプリを発行する をご覧ください。For a tutorial experience on publishing an ASP.NET Core app to an IIS server, see IIS に ASP.NET Core アプリを発行する.

.NET Core ホスティング バンドルのインストールInstall the .NET Core Hosting Bundle

サポートされるオペレーティング システムSupported operating systems

次のオペレーティング システムがサポートされています。The following operating systems are supported:

  • Windows 7 以降Windows 7 or later
  • Windows Server 2008 R2 以降Windows Server 2008 R2 or later

HTTP.sys サーバー (旧称 WebListener) は、IIS が含まれるリバース プロキシ構成では動作しません。HTTP.sys server (formerly called WebListener) doesn't work in a reverse proxy configuration with IIS. Kestrel サーバーを使用します。Use the Kestrel server.

Azure でのホスティングの情報については、「Azure App Service に ASP.NET Core アプリを展開する」を参照してください。For information on hosting in Azure, see Azure App Service に ASP.NET Core アプリを展開する.

トラブルシューティング ガイダンスについては、「ASP.NET Core プロジェクトのトラブルシューティングとデバッグ」を参照してください。For troubleshooting guidance, see ASP.NET Core プロジェクトのトラブルシューティングとデバッグ.

サポートされているプラットフォームSupported platforms

32 ビット (x86) または 64 ビット (x64) デプロイ用に発行されるアプリがサポートされています。Apps published for 32-bit (x86) or 64-bit (x64) deployment are supported. アプリが次の条件を満たさない限り、32 ビット (x86) .NET Core SDK を使う 32 ビット アプリをデプロイします:Deploy a 32-bit app with a 32-bit (x86) .NET Core SDK unless the app:

  • 64 ビット アプリ用の大規模な仮想メモリ アドレス空間が必要。Requires the larger virtual memory address space available to a 64-bit app.
  • 大規模な IIS スタック サイズが必要。Requires the larger IIS stack size.
  • 64 ビットのネイティブの依存関係がある。Has 64-bit native dependencies.

64 ビット (x64) .NET Core SDK を使って 64 ビット アプリを発行します。Use a 64-bit (x64) .NET Core SDK to publish a 64-bit app. ホスト システム上に 64 ビット ランタイムが存在している必要があります。A 64-bit runtime must be present on the host system.

ホスティング モデルHosting models

インプロセス ホスティング モデルIn-process hosting model

インプロセス ホスティング モデルを使用する場合、ASP.NET Core アプリはその IIS ワーカー プロセスと同じプロセスで実行されます。Using in-process hosting, an ASP.NET Core app runs in the same process as its IIS worker process. インプロセス ホスティングは、パフォーマンスの点でアウトプロセス ホスティングよりも優れています。要求がループバック アダプター (発信されたネットワーク トラフィックを同じコンピューターに送り返すネットワーク インターフェイス) を介してプロキシされることがないからです。In-process hosting provides improved performance over out-of-process hosting because requests aren't proxied over the loopback adapter, a network interface that returns outgoing network traffic back to the same machine. IIS では Windows プロセス アクティブ化サービス (WAS) を使用してプロセス管理が処理されます。IIS handles process management with the Windows Process Activation Service (WAS).

ASP.NET Core モジュール:The ASP.NET Core Module:

  • アプリの初期化を実行します。Performs app initialization.
    • CoreCLR を読み込みます。Loads the CoreCLR.
    • Program.Main.Calls Program.Main.
  • IIS ネイティブ要求の有効期間を処理します。Handles the lifetime of the IIS native request.

.NET Framework をターゲットにする ASP.NET Core アプリではインプロセス ホスティング モデルはサポートされていません。The in-process hosting model isn't supported for ASP.NET Core apps that target the .NET Framework.

次の図は、IIS (ASP.NET Core モジュール) とインプロセスでホストされるアプリとの間のリレーションシップを示しています。The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted in-process:

インプロセス ホスティング シナリオの ASP.NET Core モジュール

Web からカーネル モードの HTTP.sys ドライバーに要求が届きます。A request arrives from the web to the kernel-mode HTTP.sys driver. このドライバーによって、Web サイトの構成ポート (通常は 80 (HTTP) または 443 (HTTPS)) 上で IIS へのネイティブ要求がルーティングされます。The driver routes the native request to IIS on the website's configured port, usually 80 (HTTP) or 443 (HTTPS). ASP.NET Core モジュールは、ネイティブ要求を受け取り、それを IIS HTTP サーバー (IISHttpServer) に渡します。The ASP.NET Core Module receives the native request and passes it to IIS HTTP Server (IISHttpServer). IIS HTTP サーバーは IIS 用のインプロセス サーバーの実装であり、要求がネイティブからマネージドに変換されます。IIS HTTP Server is an in-process server implementation for IIS that converts the request from native to managed.

IIS HTTP サーバーによって要求が処理された後、その要求は ASP.NET Core ミドルウェア パイプラインにプッシュされます。After the IIS HTTP Server processes the request, the request is pushed into the ASP.NET Core middleware pipeline. ミドルウェア パイプラインは要求を処理し、HttpContext インスタンスとしてアプリのロジックに渡します。The middleware pipeline handles the request and passes it on as an HttpContext instance to the app's logic. アプリの応答は、IIS の HTTP サーバーを経由して IIS に戻されます。The app's response is passed back to IIS through IIS HTTP Server. IIS は、要求を開始したクライアントに応答を送信します。IIS sends the response to the client that initiated the request.

インプロセス ホスティングは既存のアプリではオプトインになっていますが、dotnet new テンプレートは既定ではすべての IIS および IIS Express シナリオにおいてインプロセス ホスティング モデルに設定されています。In-process hosting is opt-in for existing apps, but dotnet new templates default to the in-process hosting model for all IIS and IIS Express scenarios.

CreateDefaultBuilder では、UseIIS メソッドを呼び出し、CoreCLR を起動して IIS ワーカー プロセス (w3wp.exe または iisexpress.exe) 内のアプリをホストすることで、IServer インスタンスを追加します。CreateDefaultBuilder adds an IServer instance by calling the UseIIS method to boot the CoreCLR and host the app inside of the IIS worker process (w3wp.exe or iisexpress.exe). パフォーマンス テストは、.NET Core アプリのインプロセス ホスティングでは、アプリのアウトプロセス ホスティングや Kestrel サーバーへのプロキシ要求に比べ、スループットの要求が大幅に高くなることを示しています。Performance tests indicate that hosting a .NET Core app in-process delivers significantly higher request throughput compared to hosting the app out-of-process and proxying requests to Kestrel server.

アウト プロセス ホスティング モデルOut-of-process hosting model

ASP.NET Core アプリは IIS ワーカー プロセスとは独立したプロセスで実行されるため、プロセス管理は ASP.NET Core モジュールによって処理されます。Because ASP.NET Core apps run in a process separate from the IIS worker process, the ASP.NET Core Module handles process management. モジュールでは、最初の要求が届いたときに ASP.NET Core アプリのプロセスが開始され、プロセスがシャットダウンまたはクラッシュした場合はアプリが再起動されます。The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it shuts down or crashes. この動作は、インプロセスで実行されるアプリであり、WAS (Windows プロセス アクティブ化サービス) によって管理されるアプリと基本的に同じです。This is essentially the same behavior as seen with apps that run in-process that are managed by the Windows Process Activation Service (WAS).

次の図は、IIS (ASP.NET Core モジュール) とアウトプロセスでホストされるアプリとの間のリレーションシップを示しています。The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted out-of-process:

アウト プロセス ホスティングのシナリオの ASP.NET Core モジュール

要求は、Web からカーネル モードの HTTP.sys ドライバーに到着します。Requests arrive from the web to the kernel-mode HTTP.sys driver. ドライバーは、Web サイトの構成ポート (通常は 80 (HTTP) または 443 (HTTPS)) で IIS への要求をルーティングします。The driver routes the requests to IIS on the website's configured port, usually 80 (HTTP) or 443 (HTTPS). モジュールでは、アプリのランダムなポート (ポート 80 または 443 ではありません) で Kestrel に要求が転送されます。The module forwards the requests to Kestrel on a random port for the app, which isn't port 80 or 443.

モジュールによってスタートアップ時に環境変数を介してポートが指定されると、UseIISIntegration 拡張機能によって http://localhost:{PORT} をリッスンするようにサーバーが構成されます。The module specifies the port via an environment variable at startup, and the UseIISIntegration extension configures the server to listen on http://localhost:{PORT}. 追加のチェックが実行され、モジュールから発生していない要求は拒否されます。Additional checks are performed, and requests that don't originate from the module are rejected. モジュールでは HTTPS 転送がサポートされていないため、要求は HTTPS を介して IIS によって受信された場合でも、HTTP を介して転送されます。The module doesn't support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS.

Kestrel によってモジュールから要求が取り込まれた後、その要求は ASP.NET Core ミドルウェア パイプラインにプッシュされます。After Kestrel picks up the request from the module, the request is pushed into the ASP.NET Core middleware pipeline. ミドルウェア パイプラインは要求を処理し、HttpContext インスタンスとしてアプリのロジックに渡します。The middleware pipeline handles the request and passes it on as an HttpContext instance to the app's logic. IIS 統合によって追加されたミドルウェアでは、カーネルへの要求の転送を考慮して、スキーム、リモート IP、およびパスベースが更新されます。Middleware added by IIS Integration updates the scheme, remote IP, and pathbase to account for forwarding the request to Kestrel. アプリの応答が IIS に戻され、IIS はその応答を、要求を開始した HTTP クライアントに返します。The app's response is passed back to IIS, which pushes it back out to the HTTP client that initiated the request.

ASP.NET Core モジュール構成のガイダンスについては、「ASP.NET Core モジュール」を参照してください。For ASP.NET Core Module configuration guidance, see ASP.NET Core モジュール.

ホスティングの詳細については、「Hosting in ASP.NET Core」(ASP.NET Core でのホスティング) を参照してください。For more information on hosting, see Host in ASP.NET Core.

アプリケーション構成Application configuration

IISIntegration コンポーネントを有効にするEnable the IISIntegration components

CreateWebHostBuilder (Program.cs) でホストを構築する場合は、CreateDefaultBuilder を呼び出して IIS 統合を有効にします。When building a host in CreateWebHostBuilder (Program.cs), call CreateDefaultBuilder to enable IIS integration:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        ...

CreateDefaultBuilder の詳細については、「ASP.NET Core の Web ホスト」を参照してください。For more information on CreateDefaultBuilder, see ASP.NET Core の Web ホスト.

IIS のオプションIIS options

インプロセス ホスティング モデルIn-process hosting model

IIS サーバーのオプションを構成するには、IISServerOptions 用のサービス構成を ConfigureServices に含めます。To configure IIS Server options, include a service configuration for IISServerOptions in ConfigureServices. 次の例では、AutomaticAuthentication が無効になります。The following example disables AutomaticAuthentication:

services.Configure<IISServerOptions>(options => 
{
    options.AutomaticAuthentication = false;
});
オプションOption 既定値Default 設定Setting
AutomaticAuthentication true true の場合、IIS サーバーが Windows 認証によって認証された HttpContext.User を設定します。If true, IIS Server sets the HttpContext.User authenticated by Windows Authentication. false の場合、サーバーは HttpContext.User の ID を提供するだけで、AuthenticationScheme によって明示的に要求されたときにチャレンジに応答します。If false, the server only provides an identity for HttpContext.User and responds to challenges when explicitly requested by the AuthenticationScheme. AutomaticAuthentication を機能させるためには、IIS で Windows 認証を有効にする必要があります。Windows Authentication must be enabled in IIS for AutomaticAuthentication to function. 詳細については、Windows 認証に関する記事を参照してください。For more information, see Windows Authentication.
AuthenticationDisplayName null ログイン ページでユーザーに表示名が表示されるように設定します。Sets the display name shown to users on login pages.

アウトプロセス ホスティング モデルOut-of-process hosting model

IIS オプションを構成するには、IISOptions 用のサービス構成を ConfigureServices に含めます。To configure IIS options, include a service configuration for IISOptions in ConfigureServices. 次の例では、アプリが HttpContext.Connection.ClientCertificate を設定できません。The following example prevents the app from populating HttpContext.Connection.ClientCertificate:

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});
オプションOption 既定値Default 設定Setting
AutomaticAuthentication true true の場合、IIS 統合ミドルウェアによって、Windows 認証で認証された HttpContext.User が設定されます。If true, IIS Integration Middleware sets the HttpContext.User authenticated by Windows Authentication. false の場合、ミドルウェアは HttpContext.User の ID を提供するだけで、AuthenticationScheme によって明示的に要求されたときに課題に応答します。If false, the middleware only provides an identity for HttpContext.User and responds to challenges when explicitly requested by the AuthenticationScheme. AutomaticAuthentication を機能させるためには、IIS で Windows 認証を有効にする必要があります。Windows Authentication must be enabled in IIS for AutomaticAuthentication to function. 詳細については、「Windows 認証」のトピックを参照してください。For more information, see the Windows Authentication topic.
AuthenticationDisplayName null ログイン ページでユーザーに表示名が表示されるように設定します。Sets the display name shown to users on login pages.
ForwardClientCertificate true true の場合、MS-ASPNETCORE-CLIENTCERT 要求ヘッダーが指定されていると、HttpContext.Connection.ClientCertificate が設定されます。If true and the MS-ASPNETCORE-CLIENTCERT request header is present, the HttpContext.Connection.ClientCertificate is populated.

プロキシ サーバーとロード バランサーのシナリオProxy server and load balancer scenarios

要求が発生したスキーム (HTTP/HTTPS) とリモート IP アドレスを転送するために、Forwarded Headers Middleware を構成する IIS 統合ミドルウェアと、ASP.NET Core モジュールが構成されます。The IIS Integration Middleware, which configures Forwarded Headers Middleware, and the ASP.NET Core Module are configured to forward the scheme (HTTP/HTTPS) and the remote IP address where the request originated. 追加のプロキシ サーバーとロード バランサーの背後でホストされているアプリでは、追加の構成が必要になる場合があります。Additional configuration might be required for apps hosted behind additional proxy servers and load balancers. 詳細については、「プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する」を参照してください。For more information, see Configure ASP.NET Core to work with proxy servers and load balancers.

web.config ファイルweb.config file

web.config ファイルでは、ASP.NET Core モジュールを設定します。The web.config file configures the ASP.NET Core Module. web.config ファイルの作成、変換、および公開は、プロジェクトの公開時に、MSBuild ターゲット (_TransformWebConfig) によって処理されます。Creating, transforming, and publishing the web.config file is handled by an MSBuild target (_TransformWebConfig) when the project is published. このターゲットは、Web SDK ターゲット (Microsoft.NET.Sdk.Web) に存在します。This target is present in the Web SDK targets (Microsoft.NET.Sdk.Web). SDK は、プロジェクト ファイルの先頭で設定されています。The SDK is set at the top of the project file:

<Project Sdk="Microsoft.NET.Sdk.Web">

プロジェクト内に web.config ファイルが存在しない場合、そのファイルは ASP.NET Core モジュールを構成するための適切な processPatharguments を使用して作成され、発行された出力に移行されます。If a web.config file isn't present in the project, the file is created with the correct processPath and arguments to configure the ASP.NET Core Module and moved to published output.

プロジェクトに web.config ファイルが含まれていない場合、そのファイルは ASP.NET Core モジュールを構成するための正しい processPatharguments を使用して作成され、発行された出力に移行されます。If a web.config file is present in the project, the file is transformed with the correct processPath and arguments to configure the ASP.NET Core Module and moved to published output. 変換によりファイル内の IIS 構成の設定が変わることはありません。The transformation doesn't modify IIS configuration settings in the file.

web.config ファイルは、アクティブな IIS モジュールを制御する追加の IIS 構成設定を提供する可能性があります。The web.config file may provide additional IIS configuration settings that control active IIS modules. ASP.NET Core アプリを使用して要求を処理できる IIS モジュールの詳細については、IIS モジュールのトピックを参照してください。For information on IIS modules that are capable of processing requests with ASP.NET Core apps, see the IIS modules topic.

Web SDK によって web.config ファイルが変換されないようにするため、 <IsTransformWebConfigDisabled> プロパティをプロジェクト ファイルで使用します。To prevent the Web SDK from transforming the web.config file, use the <IsTransformWebConfigDisabled> property in the project file:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Web SDK ファイルの変換を無効にすると、 processPath引数開発者によって手動で設定する必要があります。When disabling the Web SDK from transforming the file, the processPath and arguments should be manually set by the developer. 詳細については、「ASP.NET Core モジュール」を参照してください。For more information, see ASP.NET Core モジュール.

web.config ファイルの場所web.config file location

ASP.NET Core モジュールを正しく設定するためには、web.config ファイルが、展開されるアプリのコンテンツ ルート パス (通常はアプリ ベース パス) に存在する必要があります。In order to set up the ASP.NET Core Module correctly, the web.config file must be present at the content root path (typically the app base path) of the deployed app. これは、IIS に提供される web サイトの物理パスと同じ場所です。This is the same location as the website physical path provided to IIS. Web.config ファイルは、Web 配置を使用して複数のアプリの発行を有効にするため、アプリのルートで必要です。The web.config file is required at the root of the app to enable the publishing of multiple apps using Web Deploy.

アプリの物理パスには、 <assembly>.runtimeconfig.json<assembly>.xml (XML ドキュメントのコメント)、 <assembly>.deps.json などの機密性の高いファイルが存在します。Sensitive files exist on the app's physical path, such as <assembly>.runtimeconfig.json, <assembly>.xml (XML Documentation comments), and <assembly>.deps.json. web.config ファイルが存在し、サイトは通常どおり起動した場合、IIS は、これらの機密性の高いファイルが要求された場合にファイルを提供しません。When the web.config file is present and the site starts normally, IIS doesn't serve these sensitive files if they're requested. web.configファイルが存在しないか、不適切な名前が付けられているか、または通常の起動用にサイトを構成できない場合、IIS が機密性の高いファイルを公開する可能性があります。If the web.config file is missing, incorrectly named, or unable to configure the site for normal startup, IIS may serve sensitive files publicly.

web.configファイルは、展開環境に常に存在し、適切な名前が付けられ、通常の起動用にサイトを構成できる必要があります。web.config ファイルを運用環境の展開から削除しないでください。The web.config file must be present in the deployment at all times, correctly named, and able to configure the site for normal start up. Never remove the web.config file from a production deployment.

web.config を変換するTransform web.config

発行時に web.config を変換する必要がある場合 (たとえば、構成、プロファイル、環境に基づいて環境変数を設定する場合) は、web.config を変換する を参照してください。If you need to transform web.config on publish (for example, set environment variables based on the configuration, profile, or environment), see web.config を変換する.

IIS 構成IIS configuration

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

Web サーバー (IIS) サーバーの役割を有効にし、役割のサービスを設定します。Enable the Web Server (IIS) server role and establish role services.

  1. [管理] メニューから役割と機能の追加ウィザードを使用するか、サーバー マネージャーにあるリンクを使用します。Use the Add Roles and Features wizard from the Manage menu or the link in Server Manager. [サーバーの役割] のステップで、 [Web サーバー (IIS)] チェック ボックスをオンにします。On the Server Roles step, check the box for Web Server (IIS).

    [サーバーの役割の選択] のステップで Web サーバー IIS の役割を選択します。

  2. [機能] のステップの後に、 [役割サービスの] のステップで Web サーバー (IIS) を読み込みます。After the Features step, the Role services step loads for Web Server (IIS). 希望する IIS の役割サービスを選択するか、既定の役割サービスをそのまま使用します。Select the IIS role services desired or accept the default role services provided.

    [役割サービスの選択] のステップで既定の役割サービスを選択します。

    Windows 認証 (任意)Windows Authentication (Optional)
    Windows 認証を有効にするには、 [Web サーバー] > [セキュリティ] ノードを展開します。To enable Windows Authentication, expand the following nodes: Web Server > Security. [Windows 認証] 機能を選択します。Select the Windows Authentication feature. 詳細については、「Windows Authentication <windowsAuthentication>」および「Configure Windows authentication」(Windows 認証の構成) を参照してください。For more information, see Windows Authentication <windowsAuthentication> and Configure Windows authentication.

    Websocket (省略可能)WebSockets (Optional)
    WebSockets は、ASP.NET Core 1.1 以降でサポートされています。WebSockets is supported with ASP.NET Core 1.1 or later. WebSocket を有効にするには、 [Web サーバー] > [アプリケーション開発] ノードを展開します。To enable WebSockets, expand the following nodes: Web Server > Application Development. [WebSocket プロトコル] 機能を選択します。Select the WebSocket Protocol feature. 詳細については、WebSockets に関するページを参照してください。For more information, see WebSockets.

  3. [確認] のステップを経て Web サーバーの役割とサービスをインストールします。Proceed through the Confirmation step to install the web server role and services. Web サーバー (IIS) の役割をインストールした後、サーバーと IIS の再起動は必要ありません。A server/IIS restart isn't required after installing the Web Server (IIS) role.

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

[IIS 管理コンソール][World Wide Web サービス] を有効にします。Enable the IIS Management Console and World Wide Web Services.

  1. [コントロール パネル] > [プログラム] > [プログラムと機能] > [Windows の機能の有効化または無効化] (画面の左側) に移動します。Navigate to Control Panel > Programs > Programs and Features > Turn Windows features on or off (left side of the screen).

  2. インターネット インフォメーション サービス (IIS) ノードを開きます。Open the Internet Information Services node. [Web 管理ツール] ノードを開きます。Open the Web Management Tools node.

  3. [IIS 管理コンソール] チェック ボックスをオンにします。Check the box for IIS Management Console.

  4. [World Wide Web サービス] チェック ボックスをオンにします。Check the box for World Wide Web Services.

  5. [World Wide Web サービス] の既定の機能をそのまま使用するか、IIS 機能をカスタマイズします。Accept the default features for World Wide Web Services or customize the IIS features.

    Windows 認証 (任意)Windows Authentication (Optional)
    Windows 認証を有効にするには、 [World Wide Web サービス] > [セキュリティ] ノードを展開します。To enable Windows Authentication, expand the following nodes: World Wide Web Services > Security. [Windows 認証] 機能を選択します。Select the Windows Authentication feature. 詳細については、「Windows Authentication <windowsAuthentication>」および「Configure Windows authentication」(Windows 認証の構成) を参照してください。For more information, see Windows Authentication <windowsAuthentication> and Configure Windows authentication.

    Websocket (省略可能)WebSockets (Optional)
    WebSockets は、ASP.NET Core 1.1 以降でサポートされています。WebSockets is supported with ASP.NET Core 1.1 or later. WebSocket を有効にするには、 [World Wide Web サービス] > [アプリケーション開発機能] ノードを展開します。To enable WebSockets, expand the following nodes: World Wide Web Services > Application Development Features. [WebSocket プロトコル] 機能を選択します。Select the WebSocket Protocol feature. 詳細については、WebSockets に関するページを参照してください。For more information, see WebSockets.

  6. IIS のインストールに再起動が必要な場合は、システムを再起動します。If the IIS installation requires a restart, restart the system.

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

.NET Core ホスティング バンドルのインストールInstall the .NET Core Hosting Bundle

ホスティング システムに .NET Core ホスティング バンドルをインストールします。Install the .NET Core Hosting Bundle on the hosting system. このバンドルをインストールすることで、.NET Core ランタイム、.NET Core ライブラリ、ASP.NET Core モジュールがインストールされます。The bundle installs the .NET Core Runtime, .NET Core Library, and the ASP.NET Core Module. このモジュールでは、ASP.NET Core アプリが IIS の背後で実行できるようになります。The module allows ASP.NET Core apps to run behind IIS.

重要

ホスティング バンドルが IIS の前にインストールされている場合、バンドルのインストールを修復する必要があります。If the Hosting Bundle is installed before IIS, the bundle installation must be repaired. IIS をインストールした後に、ホスティング バンドル インストーラーをもう一度実行します。Run the Hosting Bundle installer again after installing IIS.

.NET Core の 64 ビット (x64) バージョンをインストールした後、ホスティング バンドルをインストールした場合は、SDK が表示されない可能性があります (.NET Core SDK が検出されない)。If the Hosting Bundle is installed after installing the 64-bit (x64) version of .NET Core, SDKs might appear to be missing (No .NET Core SDKs were detected). この問題を解決するには、ASP.NET Core プロジェクトのトラブルシューティングとデバッグ を参照してください。To resolve the problem, see ASP.NET Core プロジェクトのトラブルシューティングとデバッグ.

直接ダウンロード (現在のバージョン)Direct download (current version)

次のリンクを使用してインストーラーをダウンロードします。Download the installer using the following link:

現在の .NET Core ホスティング バンドルのインストーラー (直接ダウンロード)Current .NET Core Hosting Bundle installer (direct download)

以前のバージョンのインストーラーEarlier versions of the installer

以前のバージョンのインストーラーを入手するには:To obtain an earlier version of the installer:

  1. .NET のダウンロードのアーカイブに移動します。Navigate to the .NET download archives.
  2. [.NET Core] の下で、.NET Core のバージョンを選択します。Under .NET Core, select the .NET Core version.
  3. [Run apps - Runtime](アプリの実行 - ランタイム) 列から、目的の .NET Core ランタイム バージョンの行を探します。In the Run apps - Runtime column, find the row of the .NET Core runtime version desired.
  4. [Runtime & Hosting Bundle](ランタイム & ホスティング バンドル) のリンクを使用してインストーラーをダウンロードします。Download the installer using the Runtime & Hosting Bundle link.

警告

一部のインストーラーには、有効期限 (EOL) に達して Microsoft によるサポートが終了した、リリース バージョンが含まれています。Some installers contain release versions that have reached their end of life (EOL) and are no longer supported by Microsoft. 詳細については、サポート ポリシーをご覧ください。For more information, see the support policy.

ホスティング バンドルをインストールするInstall the Hosting Bundle

  1. サーバーでインストーラーを実行します。Run the installer on the server. 管理者のコマンド シェルからインストーラーを実行する場合、次のパラメーターを使用できます。The following parameters are available when running the installer from an administrator command shell:

    • OPT_NO_ANCM=1 – ASP.NET Core モジュールのインストールをスキップします。OPT_NO_ANCM=1 – Skip installing the ASP.NET Core Module.
    • OPT_NO_RUNTIME=1 – .NET Core ランタイムのインストールをスキップします。OPT_NO_RUNTIME=1 – Skip installing the .NET Core runtime. サーバーが自己完結型の展開 (SCD) のみをホストする場合に使用します。Used when the server only hosts self-contained deployments (SCD).
    • OPT_NO_SHAREDFX=1 – ASP.NET Shared Framework (ASP.NET ランタイム) のインストールをスキップします。OPT_NO_SHAREDFX=1 – Skip installing the ASP.NET Shared Framework (ASP.NET runtime). サーバーが自己完結型の展開 (SCD) のみをホストする場合に使用します。Used when the server only hosts self-contained deployments (SCD).
    • OPT_NO_X86=1 – x86 ランタイムのインストールをスキップします。OPT_NO_X86=1 – Skip installing x86 runtimes. 32 ビット アプリをホストしない場合は、このパラメーターを使用します。Use this parameter when you know that you won't be hosting 32-bit apps. 今後、32 ビットと 64 ビットのアプリ両方をホストする可能性がある場合は、このパラメーターを使用せずに、両方のランタイムをインストールします。If there's any chance that you will host both 32-bit and 64-bit apps in the future, don't use this parameter and install both runtimes.
    • OPT_NO_SHARED_CONFIG_CHECK=1 – 共有構成 (applicationHost.config) が IIS のインストールと同じマシン上にある場合、IIS 共有構成を使うためのチェックを無効にします。OPT_NO_SHARED_CONFIG_CHECK=1 – Disable the check for using an IIS Shared Configuration when the shared configuration (applicationHost.config) is on the same machine as the IIS installation. "ASP.NET Core 2.2 以降の Hosting Bundler インストーラーに対してのみ使用できます。 "Only available for ASP.NET Core 2.2 or later Hosting Bundler installers. 詳細については、「ASP.NET Core モジュール」を参照してください。For more information, see ASP.NET Core モジュール.
  2. システムを再起動するか、コマンドシェルで次のコマンドを実行します。Restart the system or execute the following commands in a command shell:

    net stop was /y
    net start w3svc
    

    IIS を再起動すると、インストーラーによって行われたシステム パスへの変更 (環境変数) が取得されます。Restarting IIS picks up a change to the system PATH, which is an environment variable, made by the installer.

ホスティング バンドルをインストールするときに、IIS 内の個々のサイトを手動で停止する必要はありません。It isn't necessary to manually stop individual sites in IIS when installing the Hosting Bundle. ホストされているアプリ (IIS サイト) は、IIS の再起動時に再起動します。Hosted apps (IIS sites) restart when IIS restarts. アプリは、最初の要求 (Application Initialization モジュールからの要求など) を受信すると再起動します。Apps start up again when they receive their first request, including from the Application Initialization Module.

ASP.NET Core では、共有フレームワーク パッケージの修正プログラムのリリースに対してロールフォワード動作が採用されています。ASP.NET Core adopts roll-forward behavior for patch releases of shared framework packages. IIS によってホストされているアプリが IIS で再起動された場合、そのアプリで最初の要求を受け取ったときに、各自の参照されているパッケージに対する最新の修正プログラムのリリースが読み込まれます。When apps hosted by IIS restart with IIS, the apps load with the latest patch releases of their referenced packages when they receive their first request. IIS が再起動されない場合は、アプリのワーカー プロセスがリサイクルされてアプリで最初の要求を受信したときに、アプリが再起動され、ロールフォワード動作が実行されます。If IIS isn't restarted, apps restart and exhibit roll-forward behavior when their worker processes are recycled and they receive their first request.

注意

IIS 共有構成の詳細については、「ASP.NET Core Module with IIS Shared Configuration」 (IIS 共有構成の ASP.NET Core モジュール) を参照してください。For information on IIS Shared Configuration, see ASP.NET Core Module with IIS Shared Configuration.

Visual Studio で発行する場合の Web 配置のインストールInstall Web Deploy when publishing with Visual Studio

Web 配置を使用してサーバーにアプリを展開する場合、Web 配置の最新バージョンをサーバーにインストールします。When deploying apps to servers with Web Deploy, install the latest version of Web Deploy on the server. Web 配置をインストールするには、Web Platform Installer (WebPI) を使用するか、Microsoft ダウンロード センターからインストーラーを取得します。To install Web Deploy, use the Web Platform Installer (WebPI) or obtain an installer directly from the Microsoft Download Center. WebPI を使用することをお勧めします。The preferred method is to use WebPI. WebPI は、スタンドアロンのセットアップとホスティング プロバイダー向けの構成を提供します。WebPI offers a standalone setup and a configuration for hosting providers.

IIS サイトを作成するCreate the IIS site

  1. ホスト システムで、アプリの公開フォルダーとファイルを格納するフォルダーを作成します。On the hosting system, create a folder to contain the app's published folders and files. 以下の手順では、フォルダーのパスはアプリへの物理パスとして IIS に提供されます。In a following step, the folder's path is provided to IIS as the physical path to the app. アプリの配置フォルダーとファイル レイアウトについて詳しくは、ASP.NET Core のディレクトリ構造 をご覧ください。For more information on an app's deployment folder and file layout, see ASP.NET Core のディレクトリ構造.

  2. IIS マネージャーの [接続] パネルで、サーバーのノードを開きます。In IIS Manager, open the server's node in the Connections panel. [サイト] フォルダーを右クリックします。Right-click the Sites folder. コンテキスト メニューで [Web サイトの追加] を選択します。Select Add Website from the contextual menu.

  3. [サイト名] を指定し、 [物理パス] にはアプリの配置フォルダーを設定します。Provide a Site name and set the Physical path to the app's deployment folder. [バインド] の構成を指定して [OK] を選択し、Web サイトを作成します。Provide the Binding configuration and create the website by selecting OK:

    [Web サイトの追加] のステップでサイト名、物理パス、ホスト名を指定します。

    警告

    最上位のワイルドカードのバインド ( http://*:80/http://+:80 ) は使用しては いけませんTop-level wildcard bindings (http://*:80/ and http://+:80) should not be used. 最上位のワイルドカードのバインドは、セキュリティの脆弱性に対してアプリを切り開くことができます。Top-level wildcard bindings can open up your app to security vulnerabilities. これは、強力と脆弱の両方のワイルドカードに適用されます。This applies to both strong and weak wildcards. ワイルドカードではなく、明示的なホスト名を使用します。Use explicit host names rather than wildcards. 全体の親ドメインを制御する場合、サブドメイン ワイルドカード バインド (たとえば、*.mysub.com) にこのセキュリティ リスクはありません (脆弱である *.com とは対照的)。Subdomain wildcard binding (for example, *.mysub.com) doesn't have this security risk if you control the entire parent domain (as opposed to *.com, which is vulnerable). 詳細については、rfc7230 セクション-5.4 を参照してください。See rfc7230 section-5.4 for more information.

  4. サーバーのノードでは、 [アプリケーション プール] を選択します。Under the server's node, select Application Pools.

  5. サイトのアプリケーション プールを右クリックし、コンテキスト メニューから [基本設定] を選択します。Right-click the site's app pool and select Basic Settings from the contextual menu.

  6. [アプリケーション プールの編集] ウィンドウで、 [.NET CLR バージョン][マネージド コードなし] に設定します。In the Edit Application Pool window, set the .NET CLR version to No Managed Code:

    .NET CLR バージョンとして [マネージド コードなし] を設定します。

    ASP.NET Core は、別個のプロセスで実行され、ランタイムを管理します。ASP.NET Core runs in a separate process and manages the runtime. ASP.NET Core はデスクトップ CLR (.NET CLR) の読み込みに依存しません—.NET Core 用の Core 共通言語ランタイム (CoreCLR) が起動され、ワーカー プロセスでアプリがホストされます。ASP.NET Core doesn't rely on loading the desktop CLR (.NET CLR)—the Core Common Language Runtime (CoreCLR) for .NET Core is booted to host the app in the worker process. [.NET CLR バージョン][マネージド コードなし] への設定は省略可能ですが、推奨されます。Setting the .NET CLR version to No Managed Code is optional but recommended.

  7. ASP.NET Core 2.2 以降:インプロセス ホスティング モデルを使用する 64 ビット (x64) の自己完結型展開の場合、32 ビット (x86) プロセス用のアプリケーション プールを無効にします。ASP.NET Core 2.2 or later: For a 64-bit (x64) self-contained deployment that uses the in-process hosting model, disable the app pool for 32-bit (x86) processes.

    IIS マネージャー > [アプリケーション プール][操作] サイドバーで、 [アプリケーション プールの既定値の設定] または [詳細設定] を選択します。In the Actions sidebar of IIS Manager > Application Pools, select Set Application Pool Defaults or Advanced Settings. [32 ビット アプリケーションの有効化] を探し、値を False に設定します。Locate Enable 32-Bit Applications and set the value to False. この設定はアウトプロセス ホスティングで展開されたアプリには影響しません。This setting doesn't affect apps deployed for out-of-process hosting.

  8. プロセス モデル ID に適切なアクセス許可があることを確認します。Confirm the process model identity has the proper permissions.

    アプリ プールの既定の ID ( [プロセス モデル] > [ID] ) を ApplicationPoolIdentity から別の ID に変更した場合は、アプリのフォルダー、データベース、その他の必要なリソースにアクセスするために要求されるアクセス許可が新しい ID に設定されていることを確認します。If the default identity of the app pool (Process Model > Identity) is changed from ApplicationPoolIdentity to another identity, verify that the new identity has the required permissions to access the app's folder, database, and other required resources. たとえば、アプリケーション プールには、アプリがファイルの読み取りおよび書き込みを行うフォルダーへの読み取りおよび書き込みアクセスが必要です。For example, the app pool requires read and write access to folders where the app reads and writes files.

Windows 認証の構成 (任意)Windows Authentication configuration (Optional)
詳細については、「Windows 認証を構成する」を参照してください。For more information, see Configure Windows authentication.

アプリを配置するDeploy the app

IIS サイトを作成する」セクションで確立された IIS の [物理パス] フォルダーにアプリを配置します。Deploy the app to the IIS Physical path folder that was established in the Create the IIS site section. お勧めの配置方法は Web 配置ですが、プロジェクトの publish フォルダーからホスティング システムの配置フォルダーにアプリを移動するためのオプションはいくつか存在します。Web Deploy is the recommended mechanism for deployment, but several options exist for moving the app from the project's publish folder to the hosting system's deployment folder.

Visual Studio からのアプリの展開Web Deploy with Visual Studio

Web 配置に使用する発行プロファイルの作成方法については、「Visual Studio publish profiles for ASP.NET Core app deployment」 (ASP.NET Core アプリ展開用の Visual Studio の発行プロファイル) のトピックを参照してください。See the Visual Studio publish profiles for ASP.NET Core app deployment topic to learn how to create a publish profile for use with Web Deploy. ホスティング プロバイダーから発行プロファイルまたはそれを作成するためのサポートが提供されている場合は、そのプロファイルをダウンロードし、Visual Studio の [発行] ダイアログを使用してインポートします。If the hosting provider provides a Publish Profile or support for creating one, download their profile and import it using the Visual Studio Publish dialog:

[発行] ダイアログ ページ

Visual Studio 外部での Web 配置Web Deploy outside of Visual Studio

Visual Studio の外部で、コマンド ラインから Web 配置を使用することもできます。Web Deploy can also be used outside of Visual Studio from the command line. 詳細については、Web 配置ツールに関するページを参照してください。For more information, see Web Deployment Tool.

Web 配置の代替手段Alternatives to Web Deploy

手動コピー、XcopyRobocopy、または PowerShell など、いくつかあるうちの任意の方法を使って、ホスティング システムにアプリを移動します。Use any of several methods to move the app to the hosting system, such as manual copy, Xcopy, Robocopy, or PowerShell.

IIS への ASP.NET Core の展開の詳細については、「IIS 管理者用の展開リソース」を参照してください。For more information on ASP.NET Core deployment to IIS, see the Deployment resources for IIS administrators section.

Web サイトを閲覧するBrowse the website

ホスティング システムにアプリを配置したら、アプリのパブリック エンドポイントの 1 つに要求を行います。After the app is deployed to the hosting system, make a request to one of the app's public endpoints.

次の例では、サイトは IIS のホスト名www.mysite.comポート 80 でバインドされています。In the following example, the site is bound to an IIS Host name of www.mysite.com on Port 80. http://www.mysite.com に対して要求が行われます。A request is made to http://www.mysite.com:

Microsoft Edge ブラウザーに IIS のスタートアップ ページが読み込まれています。

ロックされた展開ファイルLocked deployment files

アプリが実行中は、展開フォルダー内のファイルがロックされます。Files in the deployment folder are locked when the app is running. 展開中にロックされたファイルを上書きすることはできません。Locked files can't be overwritten during deployment. 展開でロックされているファイルをリリースするには、次のいずれかの方法を使用してアプリ プールを停止します。To release locked files in a deployment, stop the app pool using one of the following approaches:

  • Web 配置を使用し、プロジェクト ファイル内の Microsoft.NET.Sdk.Web を参照して停止します。Use Web Deploy and reference Microsoft.NET.Sdk.Web in the project file. app_offline.htm ファイルは、Web アプリのディレクトリのルートに配置されます。An app_offline.htm file is placed at the root of the web app directory. ファイルが存在する場合、ASP.NET Core モジュールはアプリを正常にシャットダウンし、展開中に app_offline.htm ファイルを提供します。When the file is present, the ASP.NET Core Module gracefully shuts down the app and serves the app_offline.htm file during the deployment. 詳細については、「ASP.NET Core モジュール構成リファレンス」を参照してください。For more information, see the ASP.NET Core Module configuration reference.

  • サーバー上の IIS マネージャーで手動によりアプリ プールを停止します。Manually stop the app pool in the IIS Manager on the server.

  • PowerShell を使用して app_offline.html をドロップします (PowerShell 5 以降が必要)。Use PowerShell to drop app_offline.htm (requires PowerShell 5 or later):

    $pathToApp = 'PATH_TO_APP'
    
    # Stop the AppPool
    New-Item -Path $pathToApp app_offline.htm
    
    # Provide script commands here to deploy the app
    
    # Restart the AppPool
    Remove-Item -Path $pathToApp app_offline.htm
    
    

データの保護Data protection

ASP.NET Core データ保護スタックは、認証で使用されるミドルウェアを含め、いくつかの ASP.NET Core ミドルウェアによって使用されます。The ASP.NET Core Data Protection stack is used by several ASP.NET Core middlewares, including middleware used in authentication. データ保護 API がユーザーのコードから呼び出されない場合でも、配置スクリプトを使用するかユーザー コードで、永続的な暗号化キー ストアを作成するようにデータ保護を構成する必要があります。Even if Data Protection APIs aren't called by user code, data protection should be configured with a deployment script or in user code to create a persistent cryptographic key store. データ保護を構成しない場合、既定でキーはメモリ内に保持され、アプリが再起動すると破棄されます。If data protection isn't configured, the keys are held in memory and discarded when the app restarts.

キーリングがメモリに格納されている場合、アプリを再起動すると次のことが行われます。If the key ring is stored in memory when the app restarts:

  • すべての cookie ベースの認証トークンは無効になります。All cookie-based authentication tokens are invalidated.
  • ユーザーは、次回の要求時に再度サインインする必要があります。Users are required to sign in again on their next request.
  • キーリングで保護されているデータは、いずれも復号化できなくなります。Any data protected with the key ring can no longer be decrypted. これには、CSRF トークンASP.NET Core MVC TempData cookie が含まれます。This may include CSRF tokens and ASP.NET Core MVC TempData cookies.

キーリングを保持するために IIS でのデータ保護を構成するには、次のいずれかの方法を使用する必要があります。To configure data protection under IIS to persist the key ring, use one of the following approaches:

  • データ保護のレジストリ キーを作成するCreate Data Protection Registry Keys

    ASP.NET Core アプリで使用されるデータ保護キーは、アプリ外部のレジストリに格納されます。Data protection keys used by ASP.NET Core apps are stored in the registry external to the apps. 特定のアプリのキーを保持するには、アプリ プール用のレジストリ キーを作成する必要があります。To persist the keys for a given app, create registry keys for the app pool.

    非 Web ファーム IIS のスタンドアロン インストールの場合、ASP.NET Core アプリで使用するアプリ プールごとに、データ保護の PowerShell スクリプト Provision-AutoGenKeys.ps1 を使用できます。For standalone, non-webfarm IIS installations, the Data Protection Provision-AutoGenKeys.ps1 PowerShell script can be used for each app pool used with an ASP.NET Core app. このスクリプトは、HKLM レジストリにレジストリ キーを作成します。そのキーは、アプリのアプリ プールのワーカー プロセス アカウントのみがアクセスできます。This script creates a registry key in the HKLM registry that's accessible only to the worker process account of the app's app pool. キーは保存時に、DPAPI を使用して、コンピューター全体に適用するキーによって暗号化されます。Keys are encrypted at rest using DPAPI with a machine-wide key.

    Web ファームのシナリオでは、UNC パスを使用してデータ保護キー リングを格納するようにアプリを構成できます。In web farm scenarios, an app can be configured to use a UNC path to store its data protection key ring. 既定では、データ保護キーは暗号化されません。By default, the data protection keys aren't encrypted. ネットワーク共有のファイルのアクセス許可が、アプリを実行する Windows アカウントに限定されていることを確認します。Ensure that the file permissions for the network share are limited to the Windows account the app runs under. 保存時のキーを保護するために、X509 証明書を使用することができます。An X509 certificate can be used to protect keys at rest. ユーザーが証明書をアップロードできるメカニズムを検討している場合、ユーザーの信頼できる証明書ストアに証明書を配置し、ユーザーのアプリが実行されるすべてのコンピューターで証明書を利用できるようにします。Consider a mechanism to allow users to upload certificates: Place certificates into the user's trusted certificate store and ensure they're available on all machines where the user's app runs. 詳細については、「ASP.NET Core データ保護の構成」を参照してください。See Configure ASP.NET Core Data Protection for details.

  • ユーザー プロファイルを読み込むための IIS アプリケーション プールを構成するConfigure the IIS Application Pool to load the user profile

    この設定は、アプリ プールの [詳細設定][プロセス モデル] セクションにあります。This setting is in the Process Model section under the Advanced Settings for the app pool. [ユーザー プロファイルの読み込み]True に設定します。Set Load User Profile to True. True に設定すると、キーはユーザー プロファイル ディレクトリに格納され、ユーザー アカウントに固有のキーと共にデータ保護 API を使って保護されます。When set to True, keys are stored in the user profile directory and protected using DPAPI with a key specific to the user account. キーは %LOCALAPPDATA%/ASP.NET/DataProtection-Keys フォルダーに保存されます。Keys are persisted to the %LOCALAPPDATA%/ASP.NET/DataProtection-Keys folder.

    アプリ プールの setProfileEnvironment 属性も有効にする必要があります。The app pool's setProfileEnvironment attribute must also be enabled. setProfileEnvironment の既定値は trueです。The default value of setProfileEnvironment is true. 一部のシナリオ (たとえば、Windows OS) では、setProfileEnvironmentfalse に設定されます。In some scenarios (for example, Windows OS), setProfileEnvironment is set to false. キーが期待どおりにユーザー プロファイル ディレクトリに格納されていない場合:If keys aren't stored in the user profile directory as expected:

    1. %windir%/system32/inetsrv/config フォルダーに移動します。Navigate to the %windir%/system32/inetsrv/config folder.
    2. applicationHost.config ファイルを開きます。Open the applicationHost.config file.
    3. <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> 要素を探します。Locate the <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> element.
    4. setProfileEnvironment 属性 (その規定値は true です) が存在しないことを確認するか、属性の値を明示的に true に設定します。Confirm that the setProfileEnvironment attribute isn't present, which defaults the value to true, or explicitly set the attribute's value to true.
  • ファイル システムをキー リング ストアとして使用するUse the file system as a key ring store

    ファイル システムをキー リング ストアとして使用するようにアプリ コードを調整します。Adjust the app code to use the file system as a key ring store. X509 証明書を使用してキー リングを保護し、その証明書が信頼された証明書であることを確認します。Use an X509 certificate to protect the key ring and ensure the certificate is a trusted certificate. 証明書が自己署名されている場合は、信頼されたルート ストアにその証明書を配置します。If the certificate is self-signed, place the certificate in the Trusted Root store.

    Web ファームで IIS を使用する場合:When using IIS in a web farm:

    • すべてのコンピューターがアクセスできるファイル共有を使用します。Use a file share that all machines can access.
    • X509 証明書を各コンピューターに配置します。Deploy an X509 certificate to each machine. コード内にデータ保護を構成します。Configure data protection in code.
  • コンピューター全体に適用するデータ保護ポリシーを設定するSet a machine-wide policy for data protection

    データ保護システムでは、データ保護 API を使用するすべてのアプリに対して、コンピューター全体に適用する既定のポリシーを設定するためのサポートは限定的です。The data protection system has limited support for setting a default machine-wide policy for all apps that consume the Data Protection APIs. 詳細については、「ASP.NET Core データ保護」を参照してください。For more information, see ASP.NET Core データ保護.

仮想ディレクトリVirtual Directories

ASP.NET Core アプリでは IIS 仮想ディレクトリはサポートされません。IIS Virtual Directories aren't supported with ASP.NET Core apps. アプリはサブアプリケーションとしてホスティングできます。An app can be hosted as a sub-application.

サブアプリケーションSub-applications

ASP.NET Core アプリは IIS サブアプリケーション (サブアプリ) としてホスティングできます。An ASP.NET Core app can be hosted as an IIS sub-application (sub-app). サブアプリのパスは、ルート アプリの URL の一部になります。The sub-app's path becomes part of the root app's URL.

サブアプリ内にある静的資産のリンクでは、チルダとスラッシュの表記 (~/) を使う必要があります。Static asset links within the sub-app should use tilde-slash (~/) notation. チルダとスラッシュの表記によりタグ ヘルパーがトリガーされ、作成される相対リンクにサブアプリのパスベースが付加されます。Tilde-slash notation triggers a Tag Helper to prepend the sub-app's pathbase to the rendered relative link. /subapp_path にあるサブアプリの場合、src="~/image.png" を使ってリンクされる画像は src="/subapp_path/image.png" として作成されます。For a sub-app at /subapp_path, an image linked with src="~/image.png" is rendered as src="/subapp_path/image.png". ルート アプリの静的ファイル ミドルウェアでは、静的ファイル要求は処理されません。The root app's Static File Middleware doesn't process the static file request. この要求は、サブアプリの静的ファイル ミドルウェアによって処理されます。The request is processed by the sub-app's Static File Middleware.

静的資産の src 属性が絶対パス (たとえば src="/image.png") に設定されている場合、リンクはサブアプリのパスベースなしで作成されます。If a static asset's src attribute is set to an absolute path (for example, src="/image.png"), the link is rendered without the sub-app's pathbase. ルート アプリの静的ファイル ミドルウェアでは、ルート アプリの Web ルートから資産を提供しようとしますが、ルート アプリから静的資産を利用できる場合を除いて 404 - Not Found 応答が返されます。The root app's Static File Middleware attempts to serve the asset from the root app's web root, which results in a 404 - Not Found response unless the static asset is available from the root app.

ある ASP.NET Core アプリを別の ASP.NET Core アプリの下でサブアプリとしてホスティングするには:To host an ASP.NET Core app as a sub-app under another ASP.NET Core app:

  1. サブアプリ用のアプリ プールを確立します。Establish an app pool for the sub-app. デスクトップ CLR (.NET CLR) ではなく、.NET Core 用の Core 共通言語ランタイム (CoreCLR) が起動されてワーカー プロセスでアプリがホストされるため、 [.NET CLR バージョン][マネージド コードなし] に設定します。Set the .NET CLR Version to No Managed Code because the Core Common Language Runtime (CoreCLR) for .NET Core is booted to host the app in the worker process, not the desktop CLR (.NET CLR).

  2. ルート サイトを IIS マネージャーに追加し、サブアプリをルート サイトの下のフォルダー内に置きます。Add the root site in IIS Manager with the sub-app in a folder under the root site.

  3. IIS マネージャーでサブアプリのフォルダーを右クリックし、 [アプリケーションへの変換] を選択します。Right-click the sub-app folder in IIS Manager and select Convert to Application.

  4. [アプリケーションの追加] ダイアログ ボックスで、 [アプリケーション プール] に対して [選択] ボタンを使い、作成したアプリケーション プールをサブアプリ用に割り当てます。In the Add Application dialog, use the Select button for the Application Pool to assign the app pool that you created for the sub-app. [OK] を選択します。Select OK.

サブアプリに対して個別のアプリ プールを割り当てることは、インプロセス ホスティング モデルを使用する場合必須となります。The assignment of a separate app pool to the sub-app is a requirement when using the in-process hosting model.

インプロセス ホスティング モデルと ASP.NET Core モジュールの構成について詳しくは、ASP.NET Core モジュール をご覧ください。For more information on the in-process hosting model and configuring the ASP.NET Core Module, see ASP.NET Core モジュール.

web.config による IIS の構成Configuration of IIS with web.config

IIS の構成は ASP.NET Core モジュールを使用した ASP.NET Core アプリで機能する IIS シナリオの web.config<system.webServer> セクションによる影響を受けます。IIS configuration is influenced by the <system.webServer> section of web.config for IIS scenarios that are functional for ASP.NET Core apps with the ASP.NET Core Module. たとえば、IIS の構成は動的な圧縮で機能します。For example, IIS configuration is functional for dynamic compression. IIS が動的な圧縮を使用するようにサーバー レベルで構成されている場合、アプリの web.config ファイルの <urlCompression> 要素を使用すると、それを ASP.NET Core アプリに対して無効にすることができます。If IIS is configured at the server level to use dynamic compression, the <urlCompression> element in the app's web.config file can disable it for an ASP.NET Core app.

詳細については、次のトピックを参照してください。For more information, see the following topics:

分離されたアプリ プール (IIS 10.0 以降でサポートされています) で実行する個別アプリに対して環境変数を設定するには、IIS のリファレンス ドキュメントで、環境変数<environmentVariables> のトピックにある AppCmd.exe コマンドのセクションを参照してください。To set environment variables for individual apps running in isolated app pools (supported for IIS 10.0 or later), see the AppCmd.exe command section of the Environment Variables <environmentVariables> topic in the IIS reference documentation.

web.config の構成のセクションConfiguration sections of web.config

web.config の ASP.NET 4.x アプリの構成セクションは、ASP.NET Core アプリの構成では使用されません。Configuration sections of ASP.NET 4.x apps in web.config aren't used by ASP.NET Core apps for configuration:

  • <system.web>
  • <appSettings>
  • <connectionStrings>
  • <location>

ASP.NET Core アプリは、他の構成プロバイダーを使用して構成されます。ASP.NET Core apps are configured using other configuration providers. 詳細については、構成に関するページを参照してください。For more information, see Configuration.

アプリケーション プールApplication Pools

アプリケーション プールの分離は、ホスティング モデルによって決定されます。App pool isolation is determined by the hosting model:

  • インプロセス ホスティング – 別のアプリケーション プールでアプリケーションを実行する必要があります。In-process hosting – Apps are required to run in separate app pools.
  • アウトプロセス ホスティング – アプリケーションをそれぞれ専用のアプリケーションプールで実行して、アプリケーションを相互に分離することをお勧めします。Out-of-process hosting – We recommend isolating the apps from each other by running each app in its own app pool.

IIS の [Web サイトの追加] ダイアログの既定では、アプリケーションごとに 1 つのアプリケーション プールです。The IIS Add Website dialog defaults to a single app pool per app. [サイト名] を指定すると、入力したテキストが自動的に [アプリケーション プール] テキストボックスに設定されます。When a Site name is provided, the text is automatically transferred to the Application pool textbox. サイトが追加されるときに、そのサイト名を使用して新しいアプリ プールが作成されます。A new app pool is created using the site name when the site is added.

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

アプリ プール ID アカウントを使用すると、ドメインやローカル アカウントを作成して管理する必要なく、一意のアカウントでアプリを実行できます。An app pool identity account allows an app to run under a unique account without having to create and manage domains or local accounts. IIS 8.0 以降の IIS 管理者ワーカー プロセス (WAS) は、新しいアプリ プールの名前で仮想アカウントを作成し、既定によってアプリ プールのワーカー プロセスをこのアカウントで実行します。On IIS 8.0 or later, the IIS Admin Worker Process (WAS) creates a virtual account with the name of the new app pool and runs the app pool's worker processes under this account by default. IIS 管理コンソールにあるアプリ プールの [詳細設定] で、IDApplicationPoolIdentity を使用するように設定されていることを確認します。In the IIS Management Console under Advanced Settings for the app pool, ensure that the Identity is set to use ApplicationPoolIdentity:

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

IIS 管理プロセスは、Windows セキュリティ システムでのアプリ プールの名前を使用して、セキュリティで保護された識別子を作成します。The IIS management process creates a secure identifier with the name of the app pool in the Windows Security System. この ID を使用してリソースを保護することができます。Resources can be secured using this identity. ただし、この ID は実際のユーザー アカウントではなく、Windows ユーザーの管理コンソールに表示されません。However, this identity isn't a real user account and doesn't show up in the Windows User Management Console.

アプリに対する IIS ワーカー プロセスのアクセス許可を昇格させる必要がある場合は、アプリを含むディレクトリのアクセス制御リスト (ACL) を変更します。If the IIS worker process requires elevated access to the app, modify the Access Control List (ACL) for the directory containing the app:

  1. エクスプローラーを開き、そのディレクトリに移動します。Open Windows Explorer and navigate to the directory.

  2. そのディレクトリを右クリックし、 [プロパティ] を選択します。Right-click on the directory and select Properties.

  3. [セキュリティ] タブの [編集] ボタンを選択し、 [追加] ボタンをクリックします。Under the Security tab, select the Edit button and then the Add button.

  4. [場所] ボタンを選択し、システムが選択されていることを確認します。Select the Locations button and make sure the system is selected.

  5. [選択するオブジェクト名を入力してください] 領域に、「IIS AppPool\<app_pool_name> 」と入力します。Enter IIS AppPool\<app_pool_name> in Enter the object names to select area. [名前の確認] を選択します。Select the Check Names button. DefaultAppPool で、IIS AppPool\DefaultAppPool を使用して名前を確認します。For the DefaultAppPool check the names using IIS AppPool\DefaultAppPool. [名前の確認] ボタンが選択されているときには、DefaultAppPool の値が、オブジェクト名領域に表示されます。When the Check Names button is selected, a value of DefaultAppPool is indicated in the object names area. オブジェクト名の領域に直接アプリケーション プール名を入力することはできません。It isn't possible to enter the app pool name directly into the object names area. オブジェクト名を確認するときには、IIS AppPool\<app_pool_name> の形式を使用します。Use the IIS AppPool\<app_pool_name> format when checking for the object name.

    アプリ フォルダーのユーザーまたはグループのダイアログを選択します。[名前の確認] を選択する前に、オブジェクト名領域で "DefaultAppPool" のアプリ プール名が "IIS AppPool" に適用されます。

  6. [OK] を選択します。Select OK.

    アプリ フォルダーのユーザーまたはグループのダイアログを選択します。[名前の確認] を選択した後に、オブジェクト名 "DefaultAppPool" がオブジェクト名領域に表示されます。

  7. 読み取り & 実行アクセス許可は、既定で付与される必要があります。Read & execute permissions should be granted by default. 必要に応じて、追加のアクセス許可を提供します。Provide additional permissions as needed.

ICACLS ツールを使用してコマンド プロンプトでアクセス許可を付与することもできます。Access can also be granted at a command prompt using the ICACLS tool. たとえば、DefaultAppPool を使用する場合、次のコマンドを使用します。Using the DefaultAppPool as an example, the following command is used:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

詳細については、「icacls」のトピックを参照してください。For more information, see the icacls topic.

HTTP/2 のサポートHTTP/2 support

HTTP/2 は、次の IIS 展開シナリオでの ASP.NET Core でサポートされます。HTTP/2 is supported with ASP.NET Core in the following IIS deployment scenarios:

  • インプロセスIn-process
    • Windows Server 2016/Windows 10 以降、IIS 10 以降Windows Server 2016/Windows 10 or later; IIS 10 or later
    • TLS 1.2 以降の接続TLS 1.2 or later connection
  • アウトプロセスOut-of-process
    • Windows Server 2016/Windows 10 以降、IIS 10 以降Windows Server 2016/Windows 10 or later; IIS 10 or later
    • 一般向けのエッジ サーバーでは HTTP/2 を使用しますが、Kestrel サーバーへのリバース プロキシ接続では HTTP/1.1 を使用します。Public-facing edge server connections use HTTP/2, but the reverse proxy connection to the Kestrel server uses HTTP/1.1.
    • TLS 1.2 以降の接続TLS 1.2 or later connection

インプロセスの展開の場合、HTTP/2 接続が確立されると、HttpRequest.Protocol によって HTTP/2 が報告されます。For an in-process deployment when an HTTP/2 connection is established, HttpRequest.Protocol reports HTTP/2. アウトプロセスの展開の場合、HTTP/2 接続が確立されると、HttpRequest.Protocol によって HTTP/1.1 が報告されます。For an out-of-process deployment when an HTTP/2 connection is established, HttpRequest.Protocol reports HTTP/1.1.

インプロセスおよびアウトプロセス ホスティング モデルの詳細については、ASP.NET Core モジュール をご覧ください。For more information on the in-process and out-of-process hosting models, see ASP.NET Core モジュール.

HTTP/2 は既定で有効になっています。HTTP/2 is enabled by default. HTTP/2 接続が確立されない場合、接続は HTTP/1.1 にフォールバックします。Connections fall back to HTTP/1.1 if an HTTP/2 connection isn't established. IIS 展開での HTTP/2 構成の詳細については、IIS での HTTP/2 に関するページを参照してください。For more information on HTTP/2 configuration with IIS deployments, see HTTP/2 on IIS.

CORS プレフライト要求CORS preflight requests

"このセクションは、.NET Framework をターゲットにした ASP.NET Core アプリにのみ適用されます。 "This section only applies to ASP.NET Core apps that target the .NET Framework.

.NET Framework をターゲットにした ASP.NET Core アプリの場合、IIS では既定で OPTIONS 要求がアプリに渡されません。For an ASP.NET Core app that targets the .NET Framework, OPTIONS requests aren't passed to the app by default in IIS. OPTIONS 要求を渡すように web.config でアプリの IIS のハンドラーを構成する方法については、ASP.NET Web API 2 でのクロスオリジン要求の有効化:CORS のしくみに関する記事をご覧ください。To learn how to configure the app's IIS handlers in web.config to pass OPTIONS requests, see Enable cross-origin requests in ASP.NET Web API 2: How CORS Works.

Application Initialization モジュールとアイドル タイムアウトApplication Initialization Module and Idle Timeout

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

Application Initialization モジュールApplication Initialization Module

"アプリのホストされているインプロセスとアウトプロセスに適用されます。 "Applies to apps hosted in-process and out-of-process.

IIS Application Initialization は、アプリ プールが開始するときまたはリサイクルされるときに、アプリに HTTP 要求を送信する IIS 機能です。IIS Application Initialization is an IIS feature that sends an HTTP request to the app when the app pool starts or is recycled. 要求によってアプリの起動がトリガーされます。The request triggers the app to start. 既定では、IIS ではアプリのルート URL (/) に対して要求が発行され、アプリが初期化されます (構成の詳細についてはその他の技術情報を参照)。By default, IIS issues a request to the app's root URL (/) to initialize the app (see the additional resources for more details on configuration).

IIS Application Initialization 役割の機能が有効になっていることを確認します。Confirm that the IIS Application Initialization role feature in enabled:

Windows 7 以降のデスクトップ システム上で、IIS をローカルで使う場合:On Windows 7 or later desktop systems when using IIS locally:

  1. [コントロール パネル] > [プログラム] > [プログラムと機能] > [Windows の機能の有効化または無効化] (画面の左側) に移動します。Navigate to Control Panel > Programs > Programs and Features > Turn Windows features on or off (left side of the screen).
  2. [インターネット インフォメーション サービス] > [World Wide Web サービス] > [アプリケーション開発機能] を開きます。Open Internet Information Services > World Wide Web Services > Application Development Features.
  3. [Application Initialization] のチェック ボックスをオンにします。Select the check box for Application Initialization.

Windows Server 2008 R2 以降の場合:On Windows Server 2008 R2 or later:

  1. [役割と機能の追加ウィザード] を開きます。Open the Add Roles and Features Wizard.
  2. [役割サービスの選択] パネルで、 [アプリケーション開発] ノードを開きます。In the Select role services panel, open the Application Development node.
  3. [Application Initialization] のチェック ボックスをオンにします。Select the check box for Application Initialization.

次の方法のいずれかを使って、サイトの Application Initialization モジュールを有効にします。Use either of the following approaches to enable the Application Initialization Module for the site:

  • IIS マネージャーを使う場合:Using IIS Manager:

    1. [接続] パネルの [アプリケーション プール] を選択します。Select Application Pools in the Connections panel.
    2. 一覧でアプリのアプリ プールを右クリックして、 [詳細設定] を選択します。Right-click the app's app pool in the list and select Advanced Settings.
    3. 既定の [開始モード][オンデマンド] です。The default Start Mode is OnDemand. [開始モード][常時実行] に設定します。Set the Start Mode to AlwaysRunning. [OK] を選択します。Select OK.
    4. [接続] パネルの [サイト] ノードを開きます。Open the Sites node in the Connections panel.
    5. アプリを右クリックして、 [Web サイトの管理] > [詳細設定] の順に選択します。Right-click the app and select Manage Website > Advanced Settings.
    6. 既定の [有効化されたプリロード] 設定は [False] です。The default Preload Enabled setting is False. [有効化されたプリロード]True に設定します。Set Preload Enabled to True. [OK] を選択します。Select OK.
  • web.config を使う場合、doAppInitAfterRestarttrue に設定した <applicationInitialization> 要素を、アプリの web.config ファイル内の <system.webServer> 要素に追加します。Using web.config, add the <applicationInitialization> element with doAppInitAfterRestart set to true to the <system.webServer> elements in the app's web.config file:

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

アイドル タイムアウトIdle Timeout

"アプリのホストされているインプロセスにのみ適用されます。 "Only applies to apps hosted in-process.

アプリがアイドル状態にならないようにするには、IIS マネージャーを使ってアプリ プールのアイドル タイムアウトを設定します。To prevent the app from idling, set the app pool's idle timeout using IIS Manager:

  1. [接続] パネルの [アプリケーション プール] を選択します。Select Application Pools in the Connections panel.
  2. 一覧でアプリのアプリ プールを右クリックして、 [詳細設定] を選択します。Right-click the app's app pool in the list and select Advanced Settings.
  3. 既定の [アイドル状態のタイムアウト (分)][20] 分です。The default Idle Time-out (minutes) is 20 minutes. [アイドル状態のタイムアウト (分)][0] (ゼロ) に設定します。Set the Idle Time-out (minutes) to 0 (zero). [OK] を選択します。Select OK.
  4. ワーカー プロセスをリサイクルします。Recycle the worker process.

アプリのホストされているアウトプロセスがタイムアウトにならないようにするには、次の方法のいずれかを使います。To prevent apps hosted out-of-process from timing out, use either of the following approaches:

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

IIS 管理者用の展開リソースDeployment resources for IIS administrators

その他の技術情報Additional resources

ASP.NET Core アプリを IIS サーバーに発行する手順のチュートリアルについては、IIS に ASP.NET Core アプリを発行する をご覧ください。For a tutorial experience on publishing an ASP.NET Core app to an IIS server, see IIS に ASP.NET Core アプリを発行する.

.NET Core ホスティング バンドルのインストールInstall the .NET Core Hosting Bundle

サポートされるオペレーティング システムSupported operating systems

次のオペレーティング システムがサポートされています。The following operating systems are supported:

  • Windows 7 以降Windows 7 or later
  • Windows Server 2008 R2 以降Windows Server 2008 R2 or later

HTTP.sys サーバー (旧称 WebListener) は、IIS が含まれるリバース プロキシ構成では動作しません。HTTP.sys server (formerly called WebListener) doesn't work in a reverse proxy configuration with IIS. Kestrel サーバーを使用します。Use the Kestrel server.

Azure でのホスティングの情報については、「Azure App Service に ASP.NET Core アプリを展開する」を参照してください。For information on hosting in Azure, see Azure App Service に ASP.NET Core アプリを展開する.

トラブルシューティング ガイダンスについては、「ASP.NET Core プロジェクトのトラブルシューティングとデバッグ」を参照してください。For troubleshooting guidance, see ASP.NET Core プロジェクトのトラブルシューティングとデバッグ.

サポートされているプラットフォームSupported platforms

32 ビット (x86) または 64 ビット (x64) デプロイ用に発行されるアプリがサポートされています。Apps published for 32-bit (x86) or 64-bit (x64) deployment are supported. アプリが次の条件を満たさない限り、32 ビット (x86) .NET Core SDK を使う 32 ビット アプリをデプロイします:Deploy a 32-bit app with a 32-bit (x86) .NET Core SDK unless the app:

  • 64 ビット アプリ用の大規模な仮想メモリ アドレス空間が必要。Requires the larger virtual memory address space available to a 64-bit app.
  • 大規模な IIS スタック サイズが必要。Requires the larger IIS stack size.
  • 64 ビットのネイティブの依存関係がある。Has 64-bit native dependencies.

64 ビット (x64) .NET Core SDK を使って 64 ビット アプリを発行します。Use a 64-bit (x64) .NET Core SDK to publish a 64-bit app. ホスト システム上に 64 ビット ランタイムが存在している必要があります。A 64-bit runtime must be present on the host system.

ASP.NET Core には、既定のクロスプラットフォーム HTTP サーバーである Kestrel サーバーが付属しています。ASP.NET Core ships with Kestrel server, a default, cross-platform HTTP server.

IIS または IIS Express を使用すると、アプリは Kestrel サーバーを使用して IIS ワーカー プロセスとは異なるプロセス内で実行されます ("プロセス外")。When using IIS or IIS Express, the app runs in a process separate from the IIS worker process (out-of-process) with the Kestrel server.

ASP.NET Core アプリは IIS ワーカー プロセスとは独立したプロセスで実行されるため、プロセス管理はモジュールによって処理されます。Because ASP.NET Core apps run in a process separate from the IIS worker process, the module handles process management. モジュールでは、最初の要求が届いたときに ASP.NET Core アプリのプロセスが開始され、プロセスがシャットダウンまたはクラッシュした場合はアプリが再起動されます。The module starts the process for the ASP.NET Core app when the first request arrives and restarts the app if it shuts down or crashes. この動作は、インプロセスで実行されるアプリであり、WAS (Windows プロセス アクティブ化サービス) によって管理されるアプリと基本的に同じです。This is essentially the same behavior as seen with apps that run in-process that are managed by the Windows Process Activation Service (WAS).

次の図は、IIS (ASP.NET Core モジュール) とアウトプロセスでホストされるアプリとの間のリレーションシップを示しています。The following diagram illustrates the relationship between IIS, the ASP.NET Core Module, and an app hosted out-of-process:

ASP.NET Core モジュール

要求は、Web からカーネル モードの HTTP.sys ドライバーに到着します。Requests arrive from the web to the kernel-mode HTTP.sys driver. ドライバーは、Web サイトの構成ポート (通常は 80 (HTTP) または 443 (HTTPS)) で IIS への要求をルーティングします。The driver routes the requests to IIS on the website's configured port, usually 80 (HTTP) or 443 (HTTPS). モジュールでは、アプリのランダムなポート (ポート 80 または 443 ではありません) で Kestrel に要求が転送されます。The module forwards the requests to Kestrel on a random port for the app, which isn't port 80 or 443.

モジュールによってスタートアップ時に環境変数を介してポートが指定されると、IIS 統合ミドルウェアによって http://localhost:{port} をリッスンするようにサーバーが構成されます。The module specifies the port via an environment variable at startup, and the IIS Integration Middleware configures the server to listen on http://localhost:{port}. 追加のチェックが実行され、モジュールから発生していない要求は拒否されます。Additional checks are performed, and requests that don't originate from the module are rejected. モジュールでは HTTPS 転送がサポートされていないため、要求は HTTPS を介して IIS によって受信された場合でも、HTTP を介して転送されます。The module doesn't support HTTPS forwarding, so requests are forwarded over HTTP even if received by IIS over HTTPS.

Kestrel によってモジュールから要求が取り込まれた後、その要求は ASP.NET Core ミドルウェア パイプラインにプッシュされます。After Kestrel picks up the request from the module, the request is pushed into the ASP.NET Core middleware pipeline. ミドルウェア パイプラインは要求を処理し、HttpContext インスタンスとしてアプリのロジックに渡します。The middleware pipeline handles the request and passes it on as an HttpContext instance to the app's logic. IIS 統合によって追加されたミドルウェアでは、カーネルへの要求の転送を考慮して、スキーム、リモート IP、およびパスベースが更新されます。Middleware added by IIS Integration updates the scheme, remote IP, and pathbase to account for forwarding the request to Kestrel. アプリの応答が IIS に戻され、IIS はその応答を、要求を開始した HTTP クライアントに返します。The app's response is passed back to IIS, which pushes it back out to the HTTP client that initiated the request.

CreateDefaultBuilderKestrel サーバーを Web サーバーとして構成し、ベース パスとポートを ASP.NET Core モジュールに構成することで、IIS 統合を有効にします。CreateDefaultBuilder configures Kestrel server as the web server and enables IIS Integration by configuring the base path and port for the ASP.NET Core Module.

ASP.NET Core モジュールでは、バックエンド プロセスに割り当てる動的なポートが生成されます。The ASP.NET Core Module generates a dynamic port to assign to the backend process. CreateDefaultBuilder では UseIISIntegration メソッドが呼び出されます。CreateDefaultBuilder calls the UseIISIntegration method. UseIISIntegration では、localhost の IP アドレス (127.0.0.1) で動的なポートをリッスンするように Kestrel が構成されます。UseIISIntegration configures Kestrel to listen on the dynamic port at the localhost IP address (127.0.0.1). 動的なポートが 1234 である場合、Kestrel は 127.0.0.1:1234 でリッスンします。If the dynamic port is 1234, Kestrel listens at 127.0.0.1:1234. この構成によって、以下から提供されるその他の URL 構成が置き換えられます。This configuration replaces other URL configurations provided by:

モジュールを使用する場合、UseUrls または Kestrel の Listen API を呼び出す必要はありません。Calls to UseUrls or Kestrel's Listen API aren't required when using the module. UseUrls または Listen が呼び出されると、IIS なしでアプリを実行しているときのみ、Kestrel で指定したポートがリッスンされます。If UseUrls or Listen is called, Kestrel listens on the port specified only when running the app without IIS.

ASP.NET Core モジュール構成のガイダンスについては、「ASP.NET Core モジュール」を参照してください。For ASP.NET Core Module configuration guidance, see ASP.NET Core モジュール.

ホスティングの詳細については、「Hosting in ASP.NET Core」(ASP.NET Core でのホスティング) を参照してください。For more information on hosting, see Host in ASP.NET Core.

アプリケーション構成Application configuration

IISIntegration コンポーネントを有効にするEnable the IISIntegration components

CreateWebHostBuilder (Program.cs) でホストを構築する場合は、CreateDefaultBuilder を呼び出して IIS 統合を有効にします。When building a host in CreateWebHostBuilder (Program.cs), call CreateDefaultBuilder to enable IIS integration:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        ...

CreateDefaultBuilder の詳細については、「ASP.NET Core の Web ホスト」を参照してください。For more information on CreateDefaultBuilder, see ASP.NET Core の Web ホスト.

IIS のオプションIIS options

オプションOption 既定値Default 設定Setting
AutomaticAuthentication true true の場合、IIS サーバーが Windows 認証によって認証された HttpContext.User を設定します。If true, IIS Server sets the HttpContext.User authenticated by Windows Authentication. false の場合、サーバーは HttpContext.User の ID を提供するだけで、AuthenticationScheme によって明示的に要求されたときにチャレンジに応答します。If false, the server only provides an identity for HttpContext.User and responds to challenges when explicitly requested by the AuthenticationScheme. AutomaticAuthentication を機能させるためには、IIS で Windows 認証を有効にする必要があります。Windows Authentication must be enabled in IIS for AutomaticAuthentication to function. 詳細については、Windows 認証に関する記事を参照してください。For more information, see Windows Authentication.
AuthenticationDisplayName null ログイン ページでユーザーに表示名が表示されるように設定します。Sets the display name shown to users on login pages.

IIS オプションを構成するには、IISOptions 用のサービス構成を ConfigureServices に含めます。To configure IIS options, include a service configuration for IISOptions in ConfigureServices. 次の例では、アプリが HttpContext.Connection.ClientCertificate を設定できません。The following example prevents the app from populating HttpContext.Connection.ClientCertificate:

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});
オプションOption 既定値Default 設定Setting
AutomaticAuthentication true true の場合、IIS 統合ミドルウェアによって、Windows 認証で認証された HttpContext.User が設定されます。If true, IIS Integration Middleware sets the HttpContext.User authenticated by Windows Authentication. false の場合、ミドルウェアは HttpContext.User の ID を提供するだけで、AuthenticationScheme によって明示的に要求されたときに課題に応答します。If false, the middleware only provides an identity for HttpContext.User and responds to challenges when explicitly requested by the AuthenticationScheme. AutomaticAuthentication を機能させるためには、IIS で Windows 認証を有効にする必要があります。Windows Authentication must be enabled in IIS for AutomaticAuthentication to function. 詳細については、「Windows 認証」のトピックを参照してください。For more information, see the Windows Authentication topic.
AuthenticationDisplayName null ログイン ページでユーザーに表示名が表示されるように設定します。Sets the display name shown to users on login pages.
ForwardClientCertificate true true の場合、MS-ASPNETCORE-CLIENTCERT 要求ヘッダーが指定されていると、HttpContext.Connection.ClientCertificate が設定されます。If true and the MS-ASPNETCORE-CLIENTCERT request header is present, the HttpContext.Connection.ClientCertificate is populated.

プロキシ サーバーとロード バランサーのシナリオProxy server and load balancer scenarios

要求が発生したスキーム (HTTP/HTTPS) とリモート IP アドレスを転送するために、Forwarded Headers Middleware を構成する IIS 統合ミドルウェアと、ASP.NET Core モジュールが構成されます。The IIS Integration Middleware, which configures Forwarded Headers Middleware, and the ASP.NET Core Module are configured to forward the scheme (HTTP/HTTPS) and the remote IP address where the request originated. 追加のプロキシ サーバーとロード バランサーの背後でホストされているアプリでは、追加の構成が必要になる場合があります。Additional configuration might be required for apps hosted behind additional proxy servers and load balancers. 詳細については、「プロキシ サーバーとロード バランサーを使用するために ASP.NET Core を構成する」を参照してください。For more information, see Configure ASP.NET Core to work with proxy servers and load balancers.

web.config ファイルweb.config file

web.config ファイルでは、ASP.NET Core モジュールを設定します。The web.config file configures the ASP.NET Core Module. web.config ファイルの作成、変換、および公開は、プロジェクトの公開時に、MSBuild ターゲット (_TransformWebConfig) によって処理されます。Creating, transforming, and publishing the web.config file is handled by an MSBuild target (_TransformWebConfig) when the project is published. このターゲットは、Web SDK ターゲット (Microsoft.NET.Sdk.Web) に存在します。This target is present in the Web SDK targets (Microsoft.NET.Sdk.Web). SDK は、プロジェクト ファイルの先頭で設定されています。The SDK is set at the top of the project file:

<Project Sdk="Microsoft.NET.Sdk.Web">

プロジェクト内に web.config ファイルが存在しない場合、そのファイルは ASP.NET Core モジュールを構成するための適切な processPatharguments を使用して作成され、発行された出力に移行されます。If a web.config file isn't present in the project, the file is created with the correct processPath and arguments to configure the ASP.NET Core Module and moved to published output.

プロジェクトに web.config ファイルが含まれていない場合、そのファイルは ASP.NET Core モジュールを構成するための正しい processPatharguments を使用して作成され、発行された出力に移行されます。If a web.config file is present in the project, the file is transformed with the correct processPath and arguments to configure the ASP.NET Core Module and moved to published output. 変換によりファイル内の IIS 構成の設定が変わることはありません。The transformation doesn't modify IIS configuration settings in the file.

web.config ファイルは、アクティブな IIS モジュールを制御する追加の IIS 構成設定を提供する可能性があります。The web.config file may provide additional IIS configuration settings that control active IIS modules. ASP.NET Core アプリを使用して要求を処理できる IIS モジュールの詳細については、IIS モジュールのトピックを参照してください。For information on IIS modules that are capable of processing requests with ASP.NET Core apps, see the IIS modules topic.

Web SDK によって web.config ファイルが変換されないようにするため、 <IsTransformWebConfigDisabled> プロパティをプロジェクト ファイルで使用します。To prevent the Web SDK from transforming the web.config file, use the <IsTransformWebConfigDisabled> property in the project file:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Web SDK ファイルの変換を無効にすると、 processPath引数開発者によって手動で設定する必要があります。When disabling the Web SDK from transforming the file, the processPath and arguments should be manually set by the developer. 詳細については、「ASP.NET Core モジュール」を参照してください。For more information, see ASP.NET Core モジュール.

web.config ファイルの場所web.config file location

ASP.NET Core モジュールを正しく設定するためには、web.config ファイルが、展開されるアプリのコンテンツ ルート パス (通常はアプリ ベース パス) に存在する必要があります。In order to set up the ASP.NET Core Module correctly, the web.config file must be present at the content root path (typically the app base path) of the deployed app. これは、IIS に提供される web サイトの物理パスと同じ場所です。This is the same location as the website physical path provided to IIS. Web.config ファイルは、Web 配置を使用して複数のアプリの発行を有効にするため、アプリのルートで必要です。The web.config file is required at the root of the app to enable the publishing of multiple apps using Web Deploy.

アプリの物理パスには、 <assembly>.runtimeconfig.json<assembly>.xml (XML ドキュメントのコメント)、 <assembly>.deps.json などの機密性の高いファイルが存在します。Sensitive files exist on the app's physical path, such as <assembly>.runtimeconfig.json, <assembly>.xml (XML Documentation comments), and <assembly>.deps.json. web.config ファイルが存在し、サイトは通常どおり起動した場合、IIS は、これらの機密性の高いファイルが要求された場合にファイルを提供しません。When the web.config file is present and the site starts normally, IIS doesn't serve these sensitive files if they're requested. web.configファイルが存在しないか、不適切な名前が付けられているか、または通常の起動用にサイトを構成できない場合、IIS が機密性の高いファイルを公開する可能性があります。If the web.config file is missing, incorrectly named, or unable to configure the site for normal startup, IIS may serve sensitive files publicly.

web.configファイルは、展開環境に常に存在し、適切な名前が付けられ、通常の起動用にサイトを構成できる必要があります。web.config ファイルを運用環境の展開から削除しないでください。The web.config file must be present in the deployment at all times, correctly named, and able to configure the site for normal start up. Never remove the web.config file from a production deployment.

web.config を変換するTransform web.config

発行時に web.config を変換する必要がある場合 (たとえば、構成、プロファイル、環境に基づいて環境変数を設定する場合) は、web.config を変換する を参照してください。If you need to transform web.config on publish (for example, set environment variables based on the configuration, profile, or environment), see web.config を変換する.

IIS 構成IIS configuration

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

Web サーバー (IIS) サーバーの役割を有効にし、役割のサービスを設定します。Enable the Web Server (IIS) server role and establish role services.

  1. [管理] メニューから役割と機能の追加ウィザードを使用するか、サーバー マネージャーにあるリンクを使用します。Use the Add Roles and Features wizard from the Manage menu or the link in Server Manager. [サーバーの役割] のステップで、 [Web サーバー (IIS)] チェック ボックスをオンにします。On the Server Roles step, check the box for Web Server (IIS).

    [サーバーの役割の選択] のステップで Web サーバー IIS の役割を選択します。

  2. [機能] のステップの後に、 [役割サービスの] のステップで Web サーバー (IIS) を読み込みます。After the Features step, the Role services step loads for Web Server (IIS). 希望する IIS の役割サービスを選択するか、既定の役割サービスをそのまま使用します。Select the IIS role services desired or accept the default role services provided.

    [役割サービスの選択] のステップで既定の役割サービスを選択します。

    Windows 認証 (任意)Windows Authentication (Optional)
    Windows 認証を有効にするには、 [Web サーバー] > [セキュリティ] ノードを展開します。To enable Windows Authentication, expand the following nodes: Web Server > Security. [Windows 認証] 機能を選択します。Select the Windows Authentication feature. 詳細については、「Windows Authentication <windowsAuthentication>」および「Configure Windows authentication」(Windows 認証の構成) を参照してください。For more information, see Windows Authentication <windowsAuthentication> and Configure Windows authentication.

    Websocket (省略可能)WebSockets (Optional)
    WebSockets は、ASP.NET Core 1.1 以降でサポートされています。WebSockets is supported with ASP.NET Core 1.1 or later. WebSocket を有効にするには、 [Web サーバー] > [アプリケーション開発] ノードを展開します。To enable WebSockets, expand the following nodes: Web Server > Application Development. [WebSocket プロトコル] 機能を選択します。Select the WebSocket Protocol feature. 詳細については、WebSockets に関するページを参照してください。For more information, see WebSockets.

  3. [確認] のステップを経て Web サーバーの役割とサービスをインストールします。Proceed through the Confirmation step to install the web server role and services. Web サーバー (IIS) の役割をインストールした後、サーバーと IIS の再起動は必要ありません。A server/IIS restart isn't required after installing the Web Server (IIS) role.

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

[IIS 管理コンソール][World Wide Web サービス] を有効にします。Enable the IIS Management Console and World Wide Web Services.

  1. [コントロール パネル] > [プログラム] > [プログラムと機能] > [Windows の機能の有効化または無効化] (画面の左側) に移動します。Navigate to Control Panel > Programs > Programs and Features > Turn Windows features on or off (left side of the screen).

  2. インターネット インフォメーション サービス (IIS) ノードを開きます。Open the Internet Information Services node. [Web 管理ツール] ノードを開きます。Open the Web Management Tools node.

  3. [IIS 管理コンソール] チェック ボックスをオンにします。Check the box for IIS Management Console.

  4. [World Wide Web サービス] チェック ボックスをオンにします。Check the box for World Wide Web Services.

  5. [World Wide Web サービス] の既定の機能をそのまま使用するか、IIS 機能をカスタマイズします。Accept the default features for World Wide Web Services or customize the IIS features.

    Windows 認証 (任意)Windows Authentication (Optional)
    Windows 認証を有効にするには、 [World Wide Web サービス] > [セキュリティ] ノードを展開します。To enable Windows Authentication, expand the following nodes: World Wide Web Services > Security. [Windows 認証] 機能を選択します。Select the Windows Authentication feature. 詳細については、「Windows Authentication <windowsAuthentication>」および「Configure Windows authentication」(Windows 認証の構成) を参照してください。For more information, see Windows Authentication <windowsAuthentication> and Configure Windows authentication.

    Websocket (省略可能)WebSockets (Optional)
    WebSockets は、ASP.NET Core 1.1 以降でサポートされています。WebSockets is supported with ASP.NET Core 1.1 or later. WebSocket を有効にするには、 [World Wide Web サービス] > [アプリケーション開発機能] ノードを展開します。To enable WebSockets, expand the following nodes: World Wide Web Services > Application Development Features. [WebSocket プロトコル] 機能を選択します。Select the WebSocket Protocol feature. 詳細については、WebSockets に関するページを参照してください。For more information, see WebSockets.

  6. IIS のインストールに再起動が必要な場合は、システムを再起動します。If the IIS installation requires a restart, restart the system.

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

.NET Core ホスティング バンドルのインストールInstall the .NET Core Hosting Bundle

ホスティング システムに .NET Core ホスティング バンドルをインストールします。Install the .NET Core Hosting Bundle on the hosting system. このバンドルをインストールすることで、.NET Core ランタイム、.NET Core ライブラリ、ASP.NET Core モジュールがインストールされます。The bundle installs the .NET Core Runtime, .NET Core Library, and the ASP.NET Core Module. このモジュールでは、ASP.NET Core アプリが IIS の背後で実行できるようになります。The module allows ASP.NET Core apps to run behind IIS.

重要

ホスティング バンドルが IIS の前にインストールされている場合、バンドルのインストールを修復する必要があります。If the Hosting Bundle is installed before IIS, the bundle installation must be repaired. IIS をインストールした後に、ホスティング バンドル インストーラーをもう一度実行します。Run the Hosting Bundle installer again after installing IIS.

.NET Core の 64 ビット (x64) バージョンをインストールした後、ホスティング バンドルをインストールした場合は、SDK が表示されない可能性があります (.NET Core SDK が検出されない)。If the Hosting Bundle is installed after installing the 64-bit (x64) version of .NET Core, SDKs might appear to be missing (No .NET Core SDKs were detected). この問題を解決するには、ASP.NET Core プロジェクトのトラブルシューティングとデバッグ を参照してください。To resolve the problem, see ASP.NET Core プロジェクトのトラブルシューティングとデバッグ.

直接ダウンロード (現在のバージョン)Direct download (current version)

次のリンクを使用してインストーラーをダウンロードします。Download the installer using the following link:

現在の .NET Core ホスティング バンドルのインストーラー (直接ダウンロード)Current .NET Core Hosting Bundle installer (direct download)

以前のバージョンのインストーラーEarlier versions of the installer

以前のバージョンのインストーラーを入手するには:To obtain an earlier version of the installer:

  1. .NET のダウンロードのアーカイブに移動します。Navigate to the .NET download archives.
  2. [.NET Core] の下で、.NET Core のバージョンを選択します。Under .NET Core, select the .NET Core version.
  3. [Run apps - Runtime](アプリの実行 - ランタイム) 列から、目的の .NET Core ランタイム バージョンの行を探します。In the Run apps - Runtime column, find the row of the .NET Core runtime version desired.
  4. [Runtime & Hosting Bundle](ランタイム & ホスティング バンドル) のリンクを使用してインストーラーをダウンロードします。Download the installer using the Runtime & Hosting Bundle link.

警告

一部のインストーラーには、有効期限 (EOL) に達して Microsoft によるサポートが終了した、リリース バージョンが含まれています。Some installers contain release versions that have reached their end of life (EOL) and are no longer supported by Microsoft. 詳細については、サポート ポリシーをご覧ください。For more information, see the support policy.

ホスティング バンドルをインストールするInstall the Hosting Bundle

  1. サーバーでインストーラーを実行します。Run the installer on the server. 管理者のコマンド シェルからインストーラーを実行する場合、次のパラメーターを使用できます。The following parameters are available when running the installer from an administrator command shell:

    • OPT_NO_ANCM=1 – ASP.NET Core モジュールのインストールをスキップします。OPT_NO_ANCM=1 – Skip installing the ASP.NET Core Module.
    • OPT_NO_RUNTIME=1 – .NET Core ランタイムのインストールをスキップします。OPT_NO_RUNTIME=1 – Skip installing the .NET Core runtime. サーバーが自己完結型の展開 (SCD) のみをホストする場合に使用します。Used when the server only hosts self-contained deployments (SCD).
    • OPT_NO_SHAREDFX=1 – ASP.NET Shared Framework (ASP.NET ランタイム) のインストールをスキップします。OPT_NO_SHAREDFX=1 – Skip installing the ASP.NET Shared Framework (ASP.NET runtime). サーバーが自己完結型の展開 (SCD) のみをホストする場合に使用します。Used when the server only hosts self-contained deployments (SCD).
    • OPT_NO_X86=1 – x86 ランタイムのインストールをスキップします。OPT_NO_X86=1 – Skip installing x86 runtimes. 32 ビット アプリをホストしない場合は、このパラメーターを使用します。Use this parameter when you know that you won't be hosting 32-bit apps. 今後、32 ビットと 64 ビットのアプリ両方をホストする可能性がある場合は、このパラメーターを使用せずに、両方のランタイムをインストールします。If there's any chance that you will host both 32-bit and 64-bit apps in the future, don't use this parameter and install both runtimes.
    • OPT_NO_SHARED_CONFIG_CHECK=1 – 共有構成 (applicationHost.config) が IIS のインストールと同じマシン上にある場合、IIS 共有構成を使うためのチェックを無効にします。OPT_NO_SHARED_CONFIG_CHECK=1 – Disable the check for using an IIS Shared Configuration when the shared configuration (applicationHost.config) is on the same machine as the IIS installation. "ASP.NET Core 2.2 以降の Hosting Bundler インストーラーに対してのみ使用できます。 "Only available for ASP.NET Core 2.2 or later Hosting Bundler installers. 詳細については、「ASP.NET Core モジュール」を参照してください。For more information, see ASP.NET Core モジュール.
  2. システムを再起動するか、コマンドシェルで次のコマンドを実行します。Restart the system or execute the following commands in a command shell:

    net stop was /y
    net start w3svc
    

    IIS を再起動すると、インストーラーによって行われたシステム パスへの変更 (環境変数) が取得されます。Restarting IIS picks up a change to the system PATH, which is an environment variable, made by the installer.

ホスティング バンドルをインストールするときに、IIS 内の個々のサイトを手動で停止する必要はありません。It isn't necessary to manually stop individual sites in IIS when installing the Hosting Bundle. ホストされているアプリ (IIS サイト) は、IIS の再起動時に再起動します。Hosted apps (IIS sites) restart when IIS restarts. アプリは、最初の要求 (Application Initialization モジュールからの要求など) を受信すると再起動します。Apps start up again when they receive their first request, including from the Application Initialization Module.

ASP.NET Core では、共有フレームワーク パッケージの修正プログラムのリリースに対してロールフォワード動作が採用されています。ASP.NET Core adopts roll-forward behavior for patch releases of shared framework packages. IIS によってホストされているアプリが IIS で再起動された場合、そのアプリで最初の要求を受け取ったときに、各自の参照されているパッケージに対する最新の修正プログラムのリリースが読み込まれます。When apps hosted by IIS restart with IIS, the apps load with the latest patch releases of their referenced packages when they receive their first request. IIS が再起動されない場合は、アプリのワーカー プロセスがリサイクルされてアプリで最初の要求を受信したときに、アプリが再起動され、ロールフォワード動作が実行されます。If IIS isn't restarted, apps restart and exhibit roll-forward behavior when their worker processes are recycled and they receive their first request.

注意

IIS 共有構成の詳細については、「ASP.NET Core Module with IIS Shared Configuration」 (IIS 共有構成の ASP.NET Core モジュール) を参照してください。For information on IIS Shared Configuration, see ASP.NET Core Module with IIS Shared Configuration.

Visual Studio で発行する場合の Web 配置のインストールInstall Web Deploy when publishing with Visual Studio

Web 配置を使用してサーバーにアプリを展開する場合、Web 配置の最新バージョンをサーバーにインストールします。When deploying apps to servers with Web Deploy, install the latest version of Web Deploy on the server. Web 配置をインストールするには、Web Platform Installer (WebPI) を使用するか、Microsoft ダウンロード センターからインストーラーを取得します。To install Web Deploy, use the Web Platform Installer (WebPI) or obtain an installer directly from the Microsoft Download Center. WebPI を使用することをお勧めします。The preferred method is to use WebPI. WebPI は、スタンドアロンのセットアップとホスティング プロバイダー向けの構成を提供します。WebPI offers a standalone setup and a configuration for hosting providers.

IIS サイトを作成するCreate the IIS site

  1. ホスト システムで、アプリの公開フォルダーとファイルを格納するフォルダーを作成します。On the hosting system, create a folder to contain the app's published folders and files. 以下の手順では、フォルダーのパスはアプリへの物理パスとして IIS に提供されます。In a following step, the folder's path is provided to IIS as the physical path to the app. アプリの配置フォルダーとファイル レイアウトについて詳しくは、ASP.NET Core のディレクトリ構造 をご覧ください。For more information on an app's deployment folder and file layout, see ASP.NET Core のディレクトリ構造.

  2. IIS マネージャーの [接続] パネルで、サーバーのノードを開きます。In IIS Manager, open the server's node in the Connections panel. [サイト] フォルダーを右クリックします。Right-click the Sites folder. コンテキスト メニューで [Web サイトの追加] を選択します。Select Add Website from the contextual menu.

  3. [サイト名] を指定し、 [物理パス] にはアプリの配置フォルダーを設定します。Provide a Site name and set the Physical path to the app's deployment folder. [バインド] の構成を指定して [OK] を選択し、Web サイトを作成します。Provide the Binding configuration and create the website by selecting OK:

    [Web サイトの追加] のステップでサイト名、物理パス、ホスト名を指定します。

    警告

    最上位のワイルドカードのバインド ( http://*:80/http://+:80 ) は使用しては いけませんTop-level wildcard bindings (http://*:80/ and http://+:80) should not be used. 最上位のワイルドカードのバインドは、セキュリティの脆弱性に対してアプリを切り開くことができます。Top-level wildcard bindings can open up your app to security vulnerabilities. これは、強力と脆弱の両方のワイルドカードに適用されます。This applies to both strong and weak wildcards. ワイルドカードではなく、明示的なホスト名を使用します。Use explicit host names rather than wildcards. 全体の親ドメインを制御する場合、サブドメイン ワイルドカード バインド (たとえば、*.mysub.com) にこのセキュリティ リスクはありません (脆弱である *.com とは対照的)。Subdomain wildcard binding (for example, *.mysub.com) doesn't have this security risk if you control the entire parent domain (as opposed to *.com, which is vulnerable). 詳細については、rfc7230 セクション-5.4 を参照してください。See rfc7230 section-5.4 for more information.

  4. サーバーのノードでは、 [アプリケーション プール] を選択します。Under the server's node, select Application Pools.

  5. サイトのアプリケーション プールを右クリックし、コンテキスト メニューから [基本設定] を選択します。Right-click the site's app pool and select Basic Settings from the contextual menu.

  6. [アプリケーション プールの編集] ウィンドウで、 [.NET CLR バージョン][マネージド コードなし] に設定します。In the Edit Application Pool window, set the .NET CLR version to No Managed Code:

    .NET CLR バージョンとして [マネージド コードなし] を設定します。

    ASP.NET Core は、別個のプロセスで実行され、ランタイムを管理します。ASP.NET Core runs in a separate process and manages the runtime. ASP.NET Core はデスクトップ CLR (.NET CLR) の読み込みに依存しません—.NET Core 用の Core 共通言語ランタイム (CoreCLR) が起動され、ワーカー プロセスでアプリがホストされます。ASP.NET Core doesn't rely on loading the desktop CLR (.NET CLR)—the Core Common Language Runtime (CoreCLR) for .NET Core is booted to host the app in the worker process. [.NET CLR バージョン][マネージド コードなし] への設定は省略可能ですが、推奨されます。Setting the .NET CLR version to No Managed Code is optional but recommended.

  7. ASP.NET Core 2.2 以降:インプロセス ホスティング モデルを使用する 64 ビット (x64) の自己完結型展開の場合、32 ビット (x86) プロセス用のアプリケーション プールを無効にします。ASP.NET Core 2.2 or later: For a 64-bit (x64) self-contained deployment that uses the in-process hosting model, disable the app pool for 32-bit (x86) processes.

    IIS マネージャー > [アプリケーション プール][操作] サイドバーで、 [アプリケーション プールの既定値の設定] または [詳細設定] を選択します。In the Actions sidebar of IIS Manager > Application Pools, select Set Application Pool Defaults or Advanced Settings. [32 ビット アプリケーションの有効化] を探し、値を False に設定します。Locate Enable 32-Bit Applications and set the value to False. この設定はアウトプロセス ホスティングで展開されたアプリには影響しません。This setting doesn't affect apps deployed for out-of-process hosting.

  8. プロセス モデル ID に適切なアクセス許可があることを確認します。Confirm the process model identity has the proper permissions.

    アプリ プールの既定の ID ( [プロセス モデル] > [ID] ) を ApplicationPoolIdentity から別の ID に変更した場合は、アプリのフォルダー、データベース、その他の必要なリソースにアクセスするために要求されるアクセス許可が新しい ID に設定されていることを確認します。If the default identity of the app pool (Process Model > Identity) is changed from ApplicationPoolIdentity to another identity, verify that the new identity has the required permissions to access the app's folder, database, and other required resources. たとえば、アプリケーション プールには、アプリがファイルの読み取りおよび書き込みを行うフォルダーへの読み取りおよび書き込みアクセスが必要です。For example, the app pool requires read and write access to folders where the app reads and writes files.

Windows 認証の構成 (任意)Windows Authentication configuration (Optional)
詳細については、「Windows 認証を構成する」を参照してください。For more information, see Configure Windows authentication.

アプリを配置するDeploy the app

IIS サイトを作成する」セクションで確立された IIS の [物理パス] フォルダーにアプリを配置します。Deploy the app to the IIS Physical path folder that was established in the Create the IIS site section. お勧めの配置方法は Web 配置ですが、プロジェクトの publish フォルダーからホスティング システムの配置フォルダーにアプリを移動するためのオプションはいくつか存在します。Web Deploy is the recommended mechanism for deployment, but several options exist for moving the app from the project's publish folder to the hosting system's deployment folder.

Visual Studio からのアプリの展開Web Deploy with Visual Studio

Web 配置に使用する発行プロファイルの作成方法については、「Visual Studio publish profiles for ASP.NET Core app deployment」 (ASP.NET Core アプリ展開用の Visual Studio の発行プロファイル) のトピックを参照してください。See the Visual Studio publish profiles for ASP.NET Core app deployment topic to learn how to create a publish profile for use with Web Deploy. ホスティング プロバイダーから発行プロファイルまたはそれを作成するためのサポートが提供されている場合は、そのプロファイルをダウンロードし、Visual Studio の [発行] ダイアログを使用してインポートします。If the hosting provider provides a Publish Profile or support for creating one, download their profile and import it using the Visual Studio Publish dialog:

[発行] ダイアログ ページ

Visual Studio 外部での Web 配置Web Deploy outside of Visual Studio

Visual Studio の外部で、コマンド ラインから Web 配置を使用することもできます。Web Deploy can also be used outside of Visual Studio from the command line. 詳細については、Web 配置ツールに関するページを参照してください。For more information, see Web Deployment Tool.

Web 配置の代替手段Alternatives to Web Deploy

手動コピー、XcopyRobocopy、または PowerShell など、いくつかあるうちの任意の方法を使って、ホスティング システムにアプリを移動します。Use any of several methods to move the app to the hosting system, such as manual copy, Xcopy, Robocopy, or PowerShell.

IIS への ASP.NET Core の展開の詳細については、「IIS 管理者用の展開リソース」を参照してください。For more information on ASP.NET Core deployment to IIS, see the Deployment resources for IIS administrators section.

Web サイトを閲覧するBrowse the website

ホスティング システムにアプリを配置したら、アプリのパブリック エンドポイントの 1 つに要求を行います。After the app is deployed to the hosting system, make a request to one of the app's public endpoints.

次の例では、サイトは IIS のホスト名www.mysite.comポート 80 でバインドされています。In the following example, the site is bound to an IIS Host name of www.mysite.com on Port 80. http://www.mysite.com に対して要求が行われます。A request is made to http://www.mysite.com:

Microsoft Edge ブラウザーに IIS のスタートアップ ページが読み込まれています。

ロックされた展開ファイルLocked deployment files

アプリが実行中は、展開フォルダー内のファイルがロックされます。Files in the deployment folder are locked when the app is running. 展開中にロックされたファイルを上書きすることはできません。Locked files can't be overwritten during deployment. 展開でロックされているファイルをリリースするには、次のいずれかの方法を使用してアプリ プールを停止します。To release locked files in a deployment, stop the app pool using one of the following approaches:

  • Web 配置を使用し、プロジェクト ファイル内の Microsoft.NET.Sdk.Web を参照して停止します。Use Web Deploy and reference Microsoft.NET.Sdk.Web in the project file. app_offline.htm ファイルは、Web アプリのディレクトリのルートに配置されます。An app_offline.htm file is placed at the root of the web app directory. ファイルが存在する場合、ASP.NET Core モジュールはアプリを正常にシャットダウンし、展開中に app_offline.htm ファイルを提供します。When the file is present, the ASP.NET Core Module gracefully shuts down the app and serves the app_offline.htm file during the deployment. 詳細については、「ASP.NET Core モジュール構成リファレンス」を参照してください。For more information, see the ASP.NET Core Module configuration reference.

  • サーバー上の IIS マネージャーで手動によりアプリ プールを停止します。Manually stop the app pool in the IIS Manager on the server.

  • PowerShell を使用して app_offline.html をドロップします (PowerShell 5 以降が必要)。Use PowerShell to drop app_offline.htm (requires PowerShell 5 or later):

    $pathToApp = 'PATH_TO_APP'
    
    # Stop the AppPool
    New-Item -Path $pathToApp app_offline.htm
    
    # Provide script commands here to deploy the app
    
    # Restart the AppPool
    Remove-Item -Path $pathToApp app_offline.htm
    
    

データの保護Data protection

ASP.NET Core データ保護スタックは、認証で使用されるミドルウェアを含め、いくつかの ASP.NET Core ミドルウェアによって使用されます。The ASP.NET Core Data Protection stack is used by several ASP.NET Core middlewares, including middleware used in authentication. データ保護 API がユーザーのコードから呼び出されない場合でも、配置スクリプトを使用するかユーザー コードで、永続的な暗号化キー ストアを作成するようにデータ保護を構成する必要があります。Even if Data Protection APIs aren't called by user code, data protection should be configured with a deployment script or in user code to create a persistent cryptographic key store. データ保護を構成しない場合、既定でキーはメモリ内に保持され、アプリが再起動すると破棄されます。If data protection isn't configured, the keys are held in memory and discarded when the app restarts.

キーリングがメモリに格納されている場合、アプリを再起動すると次のことが行われます。If the key ring is stored in memory when the app restarts:

  • すべての cookie ベースの認証トークンは無効になります。All cookie-based authentication tokens are invalidated.
  • ユーザーは、次回の要求時に再度サインインする必要があります。Users are required to sign in again on their next request.
  • キーリングで保護されているデータは、いずれも復号化できなくなります。Any data protected with the key ring can no longer be decrypted. これには、CSRF トークンASP.NET Core MVC TempData cookie が含まれます。This may include CSRF tokens and ASP.NET Core MVC TempData cookies.

キーリングを保持するために IIS でのデータ保護を構成するには、次のいずれかの方法を使用する必要があります。To configure data protection under IIS to persist the key ring, use one of the following approaches:

  • データ保護のレジストリ キーを作成するCreate Data Protection Registry Keys

    ASP.NET Core アプリで使用されるデータ保護キーは、アプリ外部のレジストリに格納されます。Data protection keys used by ASP.NET Core apps are stored in the registry external to the apps. 特定のアプリのキーを保持するには、アプリ プール用のレジストリ キーを作成する必要があります。To persist the keys for a given app, create registry keys for the app pool.

    非 Web ファーム IIS のスタンドアロン インストールの場合、ASP.NET Core アプリで使用するアプリ プールごとに、データ保護の PowerShell スクリプト Provision-AutoGenKeys.ps1 を使用できます。For standalone, non-webfarm IIS installations, the Data Protection Provision-AutoGenKeys.ps1 PowerShell script can be used for each app pool used with an ASP.NET Core app. このスクリプトは、HKLM レジストリにレジストリ キーを作成します。そのキーは、アプリのアプリ プールのワーカー プロセス アカウントのみがアクセスできます。This script creates a registry key in the HKLM registry that's accessible only to the worker process account of the app's app pool. キーは保存時に、DPAPI を使用して、コンピューター全体に適用するキーによって暗号化されます。Keys are encrypted at rest using DPAPI with a machine-wide key.

    Web ファームのシナリオでは、UNC パスを使用してデータ保護キー リングを格納するようにアプリを構成できます。In web farm scenarios, an app can be configured to use a UNC path to store its data protection key ring. 既定では、データ保護キーは暗号化されません。By default, the data protection keys aren't encrypted. ネットワーク共有のファイルのアクセス許可が、アプリを実行する Windows アカウントに限定されていることを確認します。Ensure that the file permissions for the network share are limited to the Windows account the app runs under. 保存時のキーを保護するために、X509 証明書を使用することができます。An X509 certificate can be used to protect keys at rest. ユーザーが証明書をアップロードできるメカニズムを検討している場合、ユーザーの信頼できる証明書ストアに証明書を配置し、ユーザーのアプリが実行されるすべてのコンピューターで証明書を利用できるようにします。Consider a mechanism to allow users to upload certificates: Place certificates into the user's trusted certificate store and ensure they're available on all machines where the user's app runs. 詳細については、「ASP.NET Core データ保護の構成」を参照してください。See Configure ASP.NET Core Data Protection for details.

  • ユーザー プロファイルを読み込むための IIS アプリケーション プールを構成するConfigure the IIS Application Pool to load the user profile

    この設定は、アプリ プールの [詳細設定][プロセス モデル] セクションにあります。This setting is in the Process Model section under the Advanced Settings for the app pool. [ユーザー プロファイルの読み込み]True に設定します。Set Load User Profile to True. True に設定すると、キーはユーザー プロファイル ディレクトリに格納され、ユーザー アカウントに固有のキーと共にデータ保護 API を使って保護されます。When set to True, keys are stored in the user profile directory and protected using DPAPI with a key specific to the user account. キーは %LOCALAPPDATA%/ASP.NET/DataProtection-Keys フォルダーに保存されます。Keys are persisted to the %LOCALAPPDATA%/ASP.NET/DataProtection-Keys folder.

    アプリ プールの setProfileEnvironment 属性も有効にする必要があります。The app pool's setProfileEnvironment attribute must also be enabled. setProfileEnvironment の既定値は trueです。The default value of setProfileEnvironment is true. 一部のシナリオ (たとえば、Windows OS) では、setProfileEnvironmentfalse に設定されます。In some scenarios (for example, Windows OS), setProfileEnvironment is set to false. キーが期待どおりにユーザー プロファイル ディレクトリに格納されていない場合:If keys aren't stored in the user profile directory as expected:

    1. %windir%/system32/inetsrv/config フォルダーに移動します。Navigate to the %windir%/system32/inetsrv/config folder.
    2. applicationHost.config ファイルを開きます。Open the applicationHost.config file.
    3. <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> 要素を探します。Locate the <system.applicationHost><applicationPools><applicationPoolDefaults><processModel> element.
    4. setProfileEnvironment 属性 (その規定値は true です) が存在しないことを確認するか、属性の値を明示的に true に設定します。Confirm that the setProfileEnvironment attribute isn't present, which defaults the value to true, or explicitly set the attribute's value to true.
  • ファイル システムをキー リング ストアとして使用するUse the file system as a key ring store

    ファイル システムをキー リング ストアとして使用するようにアプリ コードを調整します。Adjust the app code to use the file system as a key ring store. X509 証明書を使用してキー リングを保護し、その証明書が信頼された証明書であることを確認します。Use an X509 certificate to protect the key ring and ensure the certificate is a trusted certificate. 証明書が自己署名されている場合は、信頼されたルート ストアにその証明書を配置します。If the certificate is self-signed, place the certificate in the Trusted Root store.

    Web ファームで IIS を使用する場合:When using IIS in a web farm:

    • すべてのコンピューターがアクセスできるファイル共有を使用します。Use a file share that all machines can access.
    • X509 証明書を各コンピューターに配置します。Deploy an X509 certificate to each machine. コード内にデータ保護を構成します。Configure data protection in code.
  • コンピューター全体に適用するデータ保護ポリシーを設定するSet a machine-wide policy for data protection

    データ保護システムでは、データ保護 API を使用するすべてのアプリに対して、コンピューター全体に適用する既定のポリシーを設定するためのサポートは限定的です。The data protection system has limited support for setting a default machine-wide policy for all apps that consume the Data Protection APIs. 詳細については、「ASP.NET Core データ保護」を参照してください。For more information, see ASP.NET Core データ保護.

仮想ディレクトリVirtual Directories

ASP.NET Core アプリでは IIS 仮想ディレクトリはサポートされません。IIS Virtual Directories aren't supported with ASP.NET Core apps. アプリはサブアプリケーションとしてホスティングできます。An app can be hosted as a sub-application.

サブアプリケーションSub-applications

ASP.NET Core アプリは IIS サブアプリケーション (サブアプリ) としてホスティングできます。An ASP.NET Core app can be hosted as an IIS sub-application (sub-app). サブアプリのパスは、ルート アプリの URL の一部になります。The sub-app's path becomes part of the root app's URL.

サブアプリに、ハンドラーとして ASP.NET Core モジュールを含めることはできません。A sub-app shouldn't include the ASP.NET Core Module as a handler. このモジュールをサブアプリの web.config ファイルにハンドラーとして追加すると、サブアプリを閲覧しようとすると、エラーのある構成ファイルを参照する 500.19 内部サーバー エラー が返されます。If the module is added as a handler in a sub-app's web.config file, a 500.19 Internal Server Error referencing the faulty config file is received when attempting to browse the sub-app.

次の例は、ASP.NET Core サブアプリの発行済み web.config ファイルを示しています。The following example shows a published web.config file for an ASP.NET Core sub-app:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

ASP.NET Core アプリの下に ASP.NET Core 以外のサブアプリをホスティングする場合は、サブアプリの web.config ファイルにある継承されたハンドラーを明示的に削除します。When hosting a non-ASP.NET Core sub-app underneath an ASP.NET Core app, explicitly remove the inherited handler in the sub-app's web.config file:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore" />
    </handlers>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

サブアプリ内にある静的資産のリンクでは、チルダとスラッシュの表記 (~/) を使う必要があります。Static asset links within the sub-app should use tilde-slash (~/) notation. チルダとスラッシュの表記によりタグ ヘルパーがトリガーされ、作成される相対リンクにサブアプリのパスベースが付加されます。Tilde-slash notation triggers a Tag Helper to prepend the sub-app's pathbase to the rendered relative link. /subapp_path にあるサブアプリの場合、src="~/image.png" を使ってリンクされる画像は src="/subapp_path/image.png" として作成されます。For a sub-app at /subapp_path, an image linked with src="~/image.png" is rendered as src="/subapp_path/image.png". ルート アプリの静的ファイル ミドルウェアでは、静的ファイル要求は処理されません。The root app's Static File Middleware doesn't process the static file request. この要求は、サブアプリの静的ファイル ミドルウェアによって処理されます。The request is processed by the sub-app's Static File Middleware.

静的資産の src 属性が絶対パス (たとえば src="/image.png") に設定されている場合、リンクはサブアプリのパスベースなしで作成されます。If a static asset's src attribute is set to an absolute path (for example, src="/image.png"), the link is rendered without the sub-app's pathbase. ルート アプリの静的ファイル ミドルウェアでは、ルート アプリの Web ルートから資産を提供しようとしますが、ルート アプリから静的資産を利用できる場合を除いて 404 - Not Found 応答が返されます。The root app's Static File Middleware attempts to serve the asset from the root app's web root, which results in a 404 - Not Found response unless the static asset is available from the root app.

ある ASP.NET Core アプリを別の ASP.NET Core アプリの下でサブアプリとしてホスティングするには:To host an ASP.NET Core app as a sub-app under another ASP.NET Core app:

  1. サブアプリ用のアプリ プールを確立します。Establish an app pool for the sub-app. デスクトップ CLR (.NET CLR) ではなく、.NET Core 用の Core 共通言語ランタイム (CoreCLR) が起動されてワーカー プロセスでアプリがホストされるため、 [.NET CLR バージョン][マネージド コードなし] に設定します。Set the .NET CLR Version to No Managed Code because the Core Common Language Runtime (CoreCLR) for .NET Core is booted to host the app in the worker process, not the desktop CLR (.NET CLR).

  2. ルート サイトを IIS マネージャーに追加し、サブアプリをルート サイトの下のフォルダー内に置きます。Add the root site in IIS Manager with the sub-app in a folder under the root site.

  3. IIS マネージャーでサブアプリのフォルダーを右クリックし、 [アプリケーションへの変換] を選択します。Right-click the sub-app folder in IIS Manager and select Convert to Application.

  4. [アプリケーションの追加] ダイアログ ボックスで、 [アプリケーション プール] に対して [選択] ボタンを使い、作成したアプリケーション プールをサブアプリ用に割り当てます。In the Add Application dialog, use the Select button for the Application Pool to assign the app pool that you created for the sub-app. [OK] を選択します。Select OK.

サブアプリに対して個別のアプリ プールを割り当てることは、インプロセス ホスティング モデルを使用する場合必須となります。The assignment of a separate app pool to the sub-app is a requirement when using the in-process hosting model.

インプロセス ホスティング モデルと ASP.NET Core モジュールの構成について詳しくは、ASP.NET Core モジュール をご覧ください。For more information on the in-process hosting model and configuring the ASP.NET Core Module, see ASP.NET Core モジュール.

web.config による IIS の構成Configuration of IIS with web.config

IIS の構成は ASP.NET Core モジュールを使用した ASP.NET Core アプリで機能する IIS シナリオの web.config<system.webServer> セクションによる影響を受けます。IIS configuration is influenced by the <system.webServer> section of web.config for IIS scenarios that are functional for ASP.NET Core apps with the ASP.NET Core Module. たとえば、IIS の構成は動的な圧縮で機能します。For example, IIS configuration is functional for dynamic compression. IIS が動的な圧縮を使用するようにサーバー レベルで構成されている場合、アプリの web.config ファイルの <urlCompression> 要素を使用すると、それを ASP.NET Core アプリに対して無効にすることができます。If IIS is configured at the server level to use dynamic compression, the <urlCompression> element in the app's web.config file can disable it for an ASP.NET Core app.

詳細については、次のトピックを参照してください。For more information, see the following topics:

分離されたアプリ プール (IIS 10.0 以降でサポートされています) で実行する個別アプリに対して環境変数を設定するには、IIS のリファレンス ドキュメントで、環境変数<environmentVariables> のトピックにある AppCmd.exe コマンドのセクションを参照してください。To set environment variables for individual apps running in isolated app pools (supported for IIS 10.0 or later), see the AppCmd.exe command section of the Environment Variables <environmentVariables> topic in the IIS reference documentation.

web.config の構成のセクションConfiguration sections of web.config

web.config の ASP.NET 4.x アプリの構成セクションは、ASP.NET Core アプリの構成では使用されません。Configuration sections of ASP.NET 4.x apps in web.config aren't used by ASP.NET Core apps for configuration:

  • <system.web>
  • <appSettings>
  • <connectionStrings>
  • <location>

ASP.NET Core アプリは、他の構成プロバイダーを使用して構成されます。ASP.NET Core apps are configured using other configuration providers. 詳細については、構成に関するページを参照してください。For more information, see Configuration.

アプリケーション プールApplication Pools

サーバーで複数の Web サイトをホストする場合は、アプリをそれぞれ専用のアプリ プールで実行して、アプリを相互に分離することをお勧めします。When hosting multiple websites on a server, we recommend isolating the apps from each other by running each app in its own app pool. IIS の [Web サイトの追加] ダイアログはこの構成の既定です。The IIS Add Website dialog defaults to this configuration. [サイト名] を指定すると、入力したテキストが自動的に [アプリケーション プール] テキストボックスに設定されます。When a Site name is provided, the text is automatically transferred to the Application pool textbox. サイトが追加されるときに、そのサイト名を使用して新しいアプリ プールが作成されます。A new app pool is created using the site name when the site is added.

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

アプリ プール ID アカウントを使用すると、ドメインやローカル アカウントを作成して管理する必要なく、一意のアカウントでアプリを実行できます。An app pool identity account allows an app to run under a unique account without having to create and manage domains or local accounts. IIS 8.0 以降の IIS 管理者ワーカー プロセス (WAS) は、新しいアプリ プールの名前で仮想アカウントを作成し、既定によってアプリ プールのワーカー プロセスをこのアカウントで実行します。On IIS 8.0 or later, the IIS Admin Worker Process (WAS) creates a virtual account with the name of the new app pool and runs the app pool's worker processes under this account by default. IIS 管理コンソールにあるアプリ プールの [詳細設定] で、IDApplicationPoolIdentity を使用するように設定されていることを確認します。In the IIS Management Console under Advanced Settings for the app pool, ensure that the Identity is set to use ApplicationPoolIdentity:

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

IIS 管理プロセスは、Windows セキュリティ システムでのアプリ プールの名前を使用して、セキュリティで保護された識別子を作成します。The IIS management process creates a secure identifier with the name of the app pool in the Windows Security System. この ID を使用してリソースを保護することができます。Resources can be secured using this identity. ただし、この ID は実際のユーザー アカウントではなく、Windows ユーザーの管理コンソールに表示されません。However, this identity isn't a real user account and doesn't show up in the Windows User Management Console.

アプリに対する IIS ワーカー プロセスのアクセス許可を昇格させる必要がある場合は、アプリを含むディレクトリのアクセス制御リスト (ACL) を変更します。If the IIS worker process requires elevated access to the app, modify the Access Control List (ACL) for the directory containing the app:

  1. エクスプローラーを開き、そのディレクトリに移動します。Open Windows Explorer and navigate to the directory.

  2. そのディレクトリを右クリックし、 [プロパティ] を選択します。Right-click on the directory and select Properties.

  3. [セキュリティ] タブの [編集] ボタンを選択し、 [追加] ボタンをクリックします。Under the Security tab, select the Edit button and then the Add button.

  4. [場所] ボタンを選択し、システムが選択されていることを確認します。Select the Locations button and make sure the system is selected.

  5. [選択するオブジェクト名を入力してください] 領域に、「IIS AppPool\<app_pool_name> 」と入力します。Enter IIS AppPool\<app_pool_name> in Enter the object names to select area. [名前の確認] を選択します。Select the Check Names button. DefaultAppPool で、IIS AppPool\DefaultAppPool を使用して名前を確認します。For the DefaultAppPool check the names using IIS AppPool\DefaultAppPool. [名前の確認] ボタンが選択されているときには、DefaultAppPool の値が、オブジェクト名領域に表示されます。When the Check Names button is selected, a value of DefaultAppPool is indicated in the object names area. オブジェクト名の領域に直接アプリケーション プール名を入力することはできません。It isn't possible to enter the app pool name directly into the object names area. オブジェクト名を確認するときには、IIS AppPool\<app_pool_name> の形式を使用します。Use the IIS AppPool\<app_pool_name> format when checking for the object name.

    アプリ フォルダーのユーザーまたはグループのダイアログを選択します。[名前の確認] を選択する前に、オブジェクト名領域で "DefaultAppPool" のアプリ プール名が "IIS AppPool" に適用されます。

  6. [OK] を選択します。Select OK.

    アプリ フォルダーのユーザーまたはグループのダイアログを選択します。[名前の確認] を選択した後に、オブジェクト名 "DefaultAppPool" がオブジェクト名領域に表示されます。

  7. 読み取り & 実行アクセス許可は、既定で付与される必要があります。Read & execute permissions should be granted by default. 必要に応じて、追加のアクセス許可を提供します。Provide additional permissions as needed.

ICACLS ツールを使用してコマンド プロンプトでアクセス許可を付与することもできます。Access can also be granted at a command prompt using the ICACLS tool. たとえば、DefaultAppPool を使用する場合、次のコマンドを使用します。Using the DefaultAppPool as an example, the following command is used:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

詳細については、「icacls」のトピックを参照してください。For more information, see the icacls topic.

HTTP/2 のサポートHTTP/2 support

次の基本要件を満たすアウトプロセスの展開には、HTTP/2 がサポートされています。HTTP/2 is supported for out-of-process deployments that meet the following base requirements:

  • Windows Server 2016/Windows 10 以降、IIS 10 以降Windows Server 2016/Windows 10 or later; IIS 10 or later
  • 一般向けのエッジ サーバーでは HTTP/2 を使用しますが、Kestrel サーバーへのリバース プロキシ接続では HTTP/1.1 を使用します。Public-facing edge server connections use HTTP/2, but the reverse proxy connection to the Kestrel server uses HTTP/1.1.
  • ターゲット フレームワーク:HTTP/2 接続は IIS によって完全に処理されるため、アウトプロセスの展開には適用できません。Target framework: Not applicable to out-of-process deployments, since the HTTP/2 connection is handled entirely by IIS.
  • TLS 1.2 以降の接続TLS 1.2 or later connection

Http/2 接続が確立されると、HttpRequest.ProtocolHTTP/1.1 を報告します。If an HTTP/2 connection is established, HttpRequest.Protocol reports HTTP/1.1.

HTTP/2 は既定で有効になっています。HTTP/2 is enabled by default. HTTP/2 接続が確立されない場合、接続は HTTP/1.1 にフォールバックします。Connections fall back to HTTP/1.1 if an HTTP/2 connection isn't established. IIS 展開での HTTP/2 構成の詳細については、IIS での HTTP/2 に関するページを参照してください。For more information on HTTP/2 configuration with IIS deployments, see HTTP/2 on IIS.

CORS プレフライト要求CORS preflight requests

"このセクションは、.NET Framework をターゲットにした ASP.NET Core アプリにのみ適用されます。 "This section only applies to ASP.NET Core apps that target the .NET Framework.

.NET Framework をターゲットにした ASP.NET Core アプリの場合、IIS では既定で OPTIONS 要求がアプリに渡されません。For an ASP.NET Core app that targets the .NET Framework, OPTIONS requests aren't passed to the app by default in IIS. OPTIONS 要求を渡すように web.config でアプリの IIS のハンドラーを構成する方法については、ASP.NET Web API 2 でのクロスオリジン要求の有効化:CORS のしくみに関する記事をご覧ください。To learn how to configure the app's IIS handlers in web.config to pass OPTIONS requests, see Enable cross-origin requests in ASP.NET Web API 2: How CORS Works.

IIS 管理者用の展開リソースDeployment resources for IIS administrators

その他の技術情報Additional resources