Skip to content

MS_ASPNETCoreDeployment

Jump to bottom
nishi_74322014 edited this page Aug 21, 2026 · 1 revision

ASP.NET Coreのデプロイ

概要

ASP.NET Coreの Web アプリの発行とデプロイ

補足（発行の基本）: 配置の実体は次の 1 コマンドで、
あとは出力フォルダをどう動かすかという話になる
（.NET Coreのデプロイ も参照）。

dotnet publish -c Release -o ./publish
方式 出力 ランタイム
FDD（既定） 小さい サーバに .NET が必要
SCD（-r linux-x64 --self-contained） 大きい 不要（同梱）
単一ファイル 1 実行ファイル 上記いずれか

Web アプリでは、サーバ側のランタイム更新を運用で回せるなら FDD、
環境を固定したい／コンテナならどちらでも、というのが目安になる。

検証

デプロイ先毎の検証と、その結果。

on IIS

以下、手順。

  • ASP.NET Core の Web アプリケーションをフォルダに発行する。

  • Windows Server Hosting (ASP.NET Core Hosting Bundle) を

    • インストールする。
    • インストール後は IIS の再起動が必要。

  • アプリケーション・プールを作成する。

.Net CLR バージョン : マネージコードなし
※ アプリケーション・プールは１アプリ、１プール。

補足（「マネージコードなし」の理由）: IIS の
アプリケーション プールにおける「.NET CLR バージョン」は、
IIS が w3wp.exe に .NET Framework の CLR を読み込むかどうかの設定である。

ASP.NET Core は .NET Framework の CLR を使わない
  → IIS 側で CLR を読み込む必要が無い
  → 「マネージ コードなし（No Managed Code）」を選ぶ
  → 無駄な初期化が省ける

**「.NET Core が使えないから」ではなく「不要だから」**という点が要点。
v4.0 のままでも動くが、意味の無い CLR が載る。

１サイト：１アプリ

  • ASP.NET Core 用に IIS サイトを作成する。

  • 物理パスを WebApplication の発行先フォルダに設定。

  • 必要に応じて Web サイトのポート番号を変更する。

  • Web"サイト"にアクセスしてデバッグ実行する。

１サイト：ｎアプリ

  • IIS サイトの仮想ディレクトリ以下に WebApplication を発行。

  • Web"アプリ"に変換し、ASP.NET Core 用 App Pool を選択。

  • Web"アプリ"にアクセスしてデバッグ実行する。

※ アプリケーション・プールは１アプリ、１プール。

補足（「1 アプリ 1 プール」が必須な理由）: ASP.NET Core を
インプロセス ホスティング（既定）で動かす場合、
1 つの w3wp.exe プロセスに載せられる ASP.NET Core アプリは 1 つだけ
である（ネイティブ ランタイムの初期化が 1 回しかできないため）。

同じアプリ プールに 2 つの ASP.NET Core アプリを入れる
  → 2 つ目が起動に失敗（HTTP 500.30 など）

ASP.NET Coreの構成（Webサイト・Webアプリ） で言う
「1 サイト n アプリ」構成にする場合も、
アプリごとに別のアプリ プールを割り当てる必要がある。

アウトプロセス ホスティング（OutOfProcess）にすれば
同居できるが、性能が落ちるため、
プールを分ける方が素直である。

デバッグ実行

補足（アタッチ先が変わった理由）: 原文が取り消し線で記録している
**「dotnet.exe → w3wp.exe に戻った」**という観測は、
ホスティング モデルの変更によるものである
（ASP.NET CoreのWebサーバ 参照）。

ホスティング モデル アタッチ先 既定
アウトプロセス（〜2.1） dotnet.exe 当時の既定
インプロセス（2.2 以降） w3wp.exe 現在の既定

原文が「.NET 5 の Hosting から」としているのは、
正確には ASP.NET Core 2.2 でインプロセスが追加され、
3.0 以降で既定になったためである
（.NET 5 で顕在化したという観測自体は妥当）。

どちらか分からない場合の確認:

# IIS のワーカー プロセス一覧（PID とアプリ プール名）
& "$env:windir\system32\inetsrv\appcmd.exe" list wp

.csproj の AspNetCoreHostingModel を見れば、
どちらでビルドされているかが分かる。

補足（現在のトラブル シュート）: IIS で 500 系が出た場合、
まず stdout ログを有効にするのが最短である。

<!-- web.config（publish 時に自動生成される） -->
<aspNetCore processPath="dotnet" arguments=".\MyApp.dll"
            stdoutLogEnabled="true" stdoutLogFile=".\logs\stdout"
            hostingModel="inprocess" />
状態コード よくある原因
500.19 web.config の構文エラー／Hosting Bundle 未インストール
500.30 アプリの起動時例外（Program.cs で落ちている）
500.31 ランタイムが見つからない（版の不一致）
500.34 同一プールに 2 つの ASP.NET Core アプリ
502.5 アウトプロセスでプロセス起動に失敗

stdoutLogEnabled は調査時のみ有効にする
（常時有効だとログが際限なく増える）。
常用には ILogger + ファイル/集約基盤を使う。

証明書の設定

Lets's Encrypt で証明書発行

  • IP アドレスの証明書は作成できない。

  • 故に、スマホからのアクセスを
    テストする場合、DNS も必要になる。

補足（開発時の HTTPS）: 本番の証明書とは別に、
開発用の自己署名証明書が .NET SDK に同梱されている。

dotnet dev-certs https --trust     # 開発用証明書を信頼済みにする
dotnet dev-certs https --clean     # 作り直す

ただし自己署名のため、スマホ等の別端末からは信頼されない。
原文の指摘通り、実機テストには実在ドメイン + 正規の証明書が要る。
近年は ngrok / dev tunnels（Visual Studio 内蔵）で
一時的な公開 URL を得る方法も一般的である。

Kestrel

dotnet run
  • Docker では、
    • 以下のように設定されているため、
ENTRYPOINT ["dotnet", "MVC_Sample.dll"]
  • 内部的には、以下のように起動している模様。
    （そのままだと、wwwroot のリソースにアクセス不可能なのでコピーが必要）
dotnet MVC_Sample.dll

補足（wwwroot がコピーされない件）: 原文の
「そのままだと wwwroot のリソースにアクセス不可能」という観測は、
Dockerfile で dotnet publish の出力ではなく
dotnet build の出力をコピーしている場合に起きる。

# publish を使えば wwwroot も含めて出力される
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY . .
RUN dotnet publish -c Release -o /app/publish

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app/publish .
ENTRYPOINT ["dotnet", "MVC_Sample.dll"]

dotnet publish は wwwroot を出力に含めるため、
明示的なコピーは不要である
（.NET CoreのDockerコンテナ化）。

コンテナ化で別途必要になるもの（.NETアプリをコンテナにデプロイ）:

ENV ASPNETCORE_URLS=http://+:8080     # 待ち受けポート
ENV ASPNETCORE_ENVIRONMENT=Production
EXPOSE 8080

.NET 8 以降、既定のポートが 80 → 8080 に変更され、
既定で非 root ユーザーで動くようになった点にも注意する。

on Linux

補足（Linux での常駐）: Linux では systemd のサービスとして
登録するのが定石である（IIS のアプリ プールに相当）。

# /etc/systemd/system/myapp.service
[Unit]
Description=MyApp

[Service]
WorkingDirectory=/var/www/myapp
ExecStart=/usr/bin/dotnet /var/www/myapp/MyApp.dll
Restart=always
RestartSec=10
User=www-data
Environment=ASPNETCORE_ENVIRONMENT=Production

[Install]
WantedBy=multi-user.target
sudo systemctl enable --now myapp
journalctl -u myapp -f          # ログ確認

前段に nginx を置く場合の設定は
ASP.NET CoreのWebサーバ を参照
（UseForwardedHeaders を忘れないこと）。

参考

.NET Coreのデプロイ

ASP.NET CoreのWebサーバ

ツール

WSL上での.NET Core開発（WSL）

Visual Studio Tools for Docker

Visual Studio Kubernetes Tools

開発基盤部会 Wiki

.NET Coreのインストールとデプロイ（DNET_DotNetCoreInstallDeploy.md）

  • CentOS
  • Ubuntu

ASP.NET Coreのインストールとデプロイ（DNET_ASPNETCoreInstallDeploy.md）

  • CentOS
  • Ubuntu

Microsoft Learn

Qiita

athome-developer's blog

Tags: 移行, .NET開発, .NET Core

このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。

NetDevInfraWiki

マイクロソフト系技術情報 Wiki
Open 棟梁 Wiki

（未着手）

開発基盤部会 Wiki

移行管理: DONE ／ TODO

Clone this wiki locally