Windows Server 2022（VM）上でASP.NET Core（.NET 8）をIISホスティングしていると、更新時に「Windows Server Hosting」用インストーラーが見つからず戸惑うことがあります。結論から言うと、探すべきは別名のパッケージで、場所も選び方も少しだけ分かりにくいのが原因です。この記事では、.NET 8.0.12へ更新する際に“何を入れるべきか”を、構成別に迷わない形で整理します。
「Windows Server Hosting」インストーラーが見つからない理由
結論から言うと、「Windows Server Hosting」という名前の個別インストーラーを探す必要はありません。ダウンロードページ上の表示名やカテゴリが変わっており、目的のファイルが「ASP.NET Core Runtime」配下の「Hosting Bundle（ホスティング バンドル）」として提供されているためです。
つまり、ダウンロードページで「.NET Runtime」は見つかるのに「Windows Server Hosting」が見当たらないときは、“探している場所が違う”のがほとんどです。IISでASP.NET Coreアプリを動かす場合、最終的に必要になるのは次の3点です。
- .NET Runtime（共通ランタイム）
- ASP.NET Core Runtime（Web向けランタイム）
- IIS連携コンポーネント（ASP.NET Core Module / ANCM など）
Hosting Bundleは、この「IIS連携」を含めてまとめて入れてくれるため、IISホスティング用途ではほぼこれ一択になります。
結論：Windows Server + IISなら「ASP.NET Core Runtime Hosting Bundle」
Windows Server 2022でIISを使い、Framework-dependent（フレームワーク依存）でASP.NET Coreアプリをホストするなら、更新時に入れるべきものは「ASP.NET Core Runtime Hosting Bundle（ホスティング バンドル）」です。
Hosting Bundleに含まれるもの
Hosting Bundleは“Webサーバーで動かすためのセット”です。概念としては次のように捉えると迷いません。
| 項目 | 役割 | Hosting Bundleに含まれるか | 補足 |
|---|---|---|---|
| .NET Runtime | 共通ランタイム（ベース） | 含まれる | 多くの.NETアプリが前提とする土台 |
| ASP.NET Core Runtime | Webアプリ向けランタイム | 含まれる | ASP.NET Coreアプリの実行に必要 |
| IIS連携（ANCM等） | IISからKestrelへ橋渡し | 含まれる | ここが「IISで動く」を成立させる中核 |
| .NET SDK | ビルド/開発ツール | 含まれない | サーバー実行だけなら通常不要（CIやビルドサーバーは別） |
「どれを入れればいいか」構成別の判断早見表
同じ.NET 8でも、ホスト方法（IISか、Kestrel直か、Self-containedか）で選ぶべきものが変わります。よくある構成を表にまとめました。
| ホスト方法 | 配置形態 | 基本的に入れるべきもの | 理由 | よくある落とし穴 |
|---|---|---|---|---|
| IIS | Framework-dependent | Hosting Bundle | IIS連携＋必要ランタイムをまとめて導入 | .NET Runtimeだけ入れてもIIS連携が不足しがち |
| IIS | Self-contained | 原則はHosting Bundle推奨 | ランタイム同梱でもIIS連携（ANCM）は別途必要になりやすい | 「同梱だから何も要らない」と思ってANCMがなくて起動しない |
| Kestrel直（Windowsサービス等） | Framework-dependent | .NET Runtime（＋必要ならASP.NET Core Runtime） | IIS連携が不要なので最小構成でOK | WebでもASP.NET Core Runtimeが必要なのを忘れる |
| Kestrel直 | Self-contained | 原則不要（アプリに同梱） | アプリ側にランタイムが入っている | セキュリティ更新は「アプリ再ビルド/再配布」で反映が必要 |
判断のコツ
- IISが関わるなら「Hosting Bundle」を第一候補にする
- 「サーバーにSDKが要るか？」はビルドするかどうかで決める（実行専用なら不要なことが多い）
- Self-containedは「サーバー側のランタイム更新が不要」になりやすい反面、更新はアプリ側で責任を持つ必要がある
ダウンロードページで迷わない探し方
「.NET Runtime」は見つかるのに「Windows Server Hosting」がない場合は、ページ内のカテゴリ選択がズレている可能性が高いです。探すときは次の見方を意識してください。
| 見たいもの | ダウンロードページ上で探すカテゴリ | 選ぶ項目名の目安 | 用途 |
|---|---|---|---|
| IISでASP.NET Coreをホスト | ASP.NET Core Runtime | Hosting Bundle / ホスティング バンドル | Windows Server（IIS）向けの定番 |
| コンソール/サービス等（Webではない） | .NET Runtime | .NET Runtime（x64/x86等） | 実行環境だけ欲しい |
| 開発・ビルド | SDK | .NET SDK | 開発機やCI |
言い換えると、「Windows Server Hosting」という単語をページ内検索して見つからなくても正常で、代わりに「Hosting Bundle」を探す、という読み替えがポイントです。
Windows Server 2022（IIS）で .NET 8.0.12 へ更新する手順
ここからは「すでにIISでASP.NET Core（.NET 8）をホストしていて、8.0.12へ更新したい」ケースを想定した手順です。運用環境ではメンテナンス時間を確保した上で実施してください。
事前確認：現在のランタイム状況を把握する
まず、今サーバーに何が入っているかを確認します。PowerShell（管理者）で以下を実行します。
dotnet --info
dotnet --list-runtimes
dotnet --list-sdks確認ポイントは次の通りです。
- Microsoft.NETCore.App 8.0.x が入っているか（.NET Runtime）
- Microsoft.AspNetCore.App 8.0.x が入っているか（ASP.NET Core Runtime）
- 複数バージョンが共存している場合、対象アプリが使うメジャーバージョン（8.0系）があるか
インストール：Hosting Bundle（8.0.12）を導入する
- Microsoftの.NETダウンロードページへ移動し、「ASP.NET Core Runtime」を選びます。
- バージョンを8.0.12に合わせ、OS/アーキテクチャ（多くのWindows Server 2022はx64）を選びます。
- 一覧から「Hosting Bundle」（ホスティング バンドル）をダウンロードします。
- インストーラーを管理者で実行し、ウィザードに従ってインストールします。
Hosting Bundleは、同じ8.0系の更新であれば基本的に上書きで進みます。運用で詰まりやすいのは次の点です。
- サーバーにアクセスが集中している時間帯に実行してしまい、アプリプール再起動やIIS再起動が必要になって影響が出る
- インストール後にIISが古いモジュールを掴んだままになり、再起動しないと反映されない
反映：IISとアプリの再起動
インストールが完了したら、少なくとも次を実施します。
- IISの再起動（またはアプリプール再起動）
- 可能ならサーバー再起動（変更範囲が大きい環境・共有環境では特に安全）
手早くIISを再起動する場合は、管理者のコマンドプロンプト/PowerShellで次のコマンドが使えます。
iisresetインストール後の確認：バージョンが8.0.12になっているか
再度、次を実行し、8.0.12が入っていることを確認します。
dotnet --list-runtimes目安として、少なくとも以下の2行（または同等）が8.0.12になっている状態を目指します。
- Microsoft.NETCore.App 8.0.12
- Microsoft.AspNetCore.App 8.0.12
また、GUIで確認する場合は「インストールされているアプリ（アプリと機能）」に、「Microsoft ASP.NET Core 8.0.x – Windows Server Hosting」のような項目が追加されていることがあります（表示名は環境や言語設定で差が出ることがあります）。
よくある勘違いと、つまずきやすいポイント
「.NET Runtimeを入れたのにIISで動かない」
原因になりやすいのは、IIS連携コンポーネント（ANCM）が未導入であることです。IISでASP.NET Coreアプリを動かす場合、IISはアプリを直接実行するというより、受け口（IIS）と実行（Kestrel）をつなぐモジュールが必要になります。これをまとめて入れるのがHosting Bundleです。
「Windowsの役割の“ASP.NET”を入れればいい？」
Windows Serverの役割/機能にある「ASP.NET」は、主に.NET Framework時代のASP.NET（System.Web）向けです。ASP.NET Core（.NET 8）とは別物で、ASP.NET CoreをIISで動かすための決定打にはなりません。
もちろんIIS自体は必要ですが、ASP.NET CoreではHosting Bundle（ANCM含む）が重要です。
「Self-containedだからサーバー側の更新は一切不要？」
Self-containedはアプリにランタイムを同梱するため、“ランタイムだけ”の観点ではサーバー側更新が不要になりやすいです。ただしIISでホストする場合は、IIS連携のためにANCMが必要になりがちです。実務では、
- Self-containedでも、IISホストならHosting Bundleを入れておく
- 更新は「サーバーのHosting Bundle」と「アプリの再配布（再ビルド）」を切り分けて考える
この2点を押さえると事故が減ります。
「x86とx64、どっちを入れる？」
多くのWindows Server 2022はx64で動いているため、基本はx64のHosting Bundleで問題ありません。迷いやすいケースとして、IISで32bitアプリ設定を有効にしている環境があります。次の観点で整理すると判断しやすいです。
| 状況 | 推奨 | 理由 | 確認ポイント |
|---|---|---|---|
| 通常のWindows Server 2022（64bit） | x64 Hosting Bundle | サーバー用途で標準 | OSが64bitか |
| 32bitに依存する事情がある | 要件に合わせてx86も検討 | 32bitプロセスで動かす必要がある | IISのアプリプール設定（32-bit有効） |
インストール後に起きがちなエラーと対処の方向性
Hosting Bundleを入れた後でも、設定やバージョンの噛み合わせでエラーになることがあります。代表例と確認ポイントをまとめます。
| 症状 | ありがちな原因 | まず見る場所 | 対処の方向性 |
|---|---|---|---|
| HTTP 500 / 502.5 で起動しない | ランタイム不足、ANCM未反映、設定ミス | イベント ビューア（Application）、IISログ | IIS再起動、Hosting Bundle再確認、web.configの設定確認 |
| 更新したはずなのにバージョンが変わらない | 古いプロセスが残っている、再起動不足 | dotnet –list-runtimes | iisreset、サーバー再起動、アプリプール停止→開始 |
| 特定アプリだけ動かない | アプリが必要とするメジャーバージョン違い | アプリのターゲット（.NET 6/7/8） | 該当メジャーのHosting Bundleを追加導入（共存可） |
| 同居アプリに影響が出た | 同一サーバーで複数アプリが混在 | 同居アプリのランタイム依存関係 | 事前に検証環境でパッチ適用テスト、ロールバック手順準備 |
検証時に便利な“確認チェックリスト”
運用の現場では「何を見ればいいか」が明確だと復旧が早くなります。最低限、次のチェック項目を押さえておくのがおすすめです。
| チェック項目 | 確認方法 | OKの目安 |
|---|---|---|
| .NET Runtimeが8.0.12になっている | dotnet --list-runtimes | Microsoft.NETCore.App 8.0.12 が存在 |
| ASP.NET Core Runtimeが8.0.12になっている | dotnet --list-runtimes | Microsoft.AspNetCore.App 8.0.12 が存在 |
| IISが更新後の状態で動いている | IIS再起動 / アプリプール再起動 | 更新前のプロセスが残っていない |
| アプリが期待通り起動する | アプリのヘルスチェックURL | HTTP 200（または想定の応答） |
| ログに異常がない | イベントビューア / アプリログ | 起動失敗・依存不足が出ていない |
複数の.NETアプリを同一サーバーで運用する場合の考え方
Windows Server 2022のVMに複数のWebアプリを同居させていると、.NETの更新が怖く感じることがあります。ここで大事なのは、
- メジャーバージョン（6/7/8）が違うアプリは、必要なHosting Bundleも別
- メジャーが同じでパッチ（8.0.11→8.0.12）の更新なら、基本的に互換性が保たれる設計
- それでも“ゼロリスク”ではないので、検証→本番の順で適用する
という整理です。
特に「古いアプリが.NET 6、別のアプリが.NET 8」と混在する環境では、必要なHosting Bundleを両方入れて共存させる運用が現実的です（共存は一般的な運用パターンです）。
まとめ：探す名前を変えるだけで解決する
.NET 8.0.12へ更新しようとして「Windows Server Hosting」が見つからない場合、多くは“パッケージ名の読み替え”で解決します。Windows Server 2022でIISホスティングするなら、探すべきは「ASP.NET Core Runtime Hosting Bundle（ホスティング バンドル）」です。
- IISでASP.NET Coreを動かすならHosting Bundleが基本
- Kestrel直なら.NET Runtime（必要に応じてASP.NET Core Runtime）
- Self-containedはランタイム同梱だが、IIS連携の観点でHosting Bundleが必要になることがある
「どれを入れればいいか」の判断に迷ったら、まず“IISかどうか”で切り分けるのが最短ルートです。
コメント