ASP.NET Core アプリケーションをOutOfProcessで動作させるには以下の設定をします。
Visual Studioを利用している場合は、ソリューションエクスプローラーでプロジェクトのノードを選択して右クリックします。
ポップアップメニューの[プロジェクト ファイルの編集]の項目をクリックします。
左側のテキストエディタ部分にプロジェクトファイルのコードが表示されます。
プロジェクトファイルのXMLの<PropertyGroup>タグ内に以下のタグを追加します。
全部小文字で記述したほうが良いです。
<AspNetCoreHostingModel>outofprocess</AspNetCoreHostingModel>
<AspNetCoreHostingModel>OutOfProcess</AspNetCoreHostingModel>
プロジェクトファイル全体は以下になります。(一例)
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
</PropertyGroup>
</Project>
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
<Nullable>enable</Nullable>
<ImplicitUsings>enable</ImplicitUsings>
<AspNetCoreHostingModel>outofprocess</AspNetCoreHostingModel>
</PropertyGroup>
</Project>
プロジェクトファイルの設定後にアプリケーションを発行します。
出力ディレクトリのweb.config を確認します。以下のファイルが生成されています。(一例)
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<location path="." inheritInChildApplications="false">
<system.webServer>
<handlers>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified" />
</handlers>
<aspNetCore processPath="dotnet" arguments=".\WebCurrentTimeDisplay.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="outofprocess" />
</system.webServer>
</location>
</configuration>
<!--ProjectGuid: 4FE1B715-2EB5-4EE0-9F29-1E7A4B7950D0-->
aspNetCoreタグにhostingModel="outofprocess"が設定されていればOKです。
<aspNetCore processPath="dotnet" arguments=".\WebCurrentTimeDisplay.dll" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout" hostingModel="outofprocess" />
発行されたファイルを配置して動作確認します。
InProcess と OutOfProcessでどのような違いがあるかを紹介します。
| 観点 | InProcess | OutOfProcess |
|---|---|---|
| 実行場所 | IIS の w3wp.exe 内 | 別プロセス（Kestrel / dotnet.exe / exe） |
| IIS との関係 | IIS が 直接アプリをホスト | IIS は リバースプロキシ |
| パフォーマンス | 高い（プロキシなし） | やや低下（IIS → アプリ転送あり） |
| レイテンシ | 低い | わずかに増える |
| アプリプール共有 | ❌ 不可（実質 1アプリ=1プール） | ✅ 可能（複数アプリ共存） |
| 500.35 エラー | 発生しやすい（複数配置で必ず） | 発生しない |
| プロセス分離 | なし（w3wp 依存） | あり（アプリごとに別プロセス） |
| 障害影響範囲 | プール内＝アプリ単体 | プール内でも アプリ単体 |
| アプリプール数 | 増えやすい | 減らしやすい |
| 運用管理コスト | 高くなりがち（プール乱立） | 低くしやすい（集約可能） |
| Identity（権限） | プール単位 | プール単位（＋アプリ側制御） |
| 設定の単純さ | 単純（ただし数が増える） | やや複雑（構成理解が必要） |
| 推奨用途 | 重要・高負荷・単独運用 | ツール系・管理系・多数アプリ |
