.NET アプリケーションの発行の概要

この記事では、.NET アプリケーションを発行するさまざまな方法について説明します。 公開モード、実行可能ファイルとクロスプラットフォーム バイナリを生成する方法、デプロイ環境とランタイム環境に対する各アプローチの影響について説明します。 .NET CLI または Visual Studio を使用して、.NET アプリケーションを発行できます。

出版とは何ですか?

.NET アプリを発行するということは、ソース コードをコンパイルして、依存関係や関連ファイルと共に実行可能ファイルまたはバイナリを作成して配布することを意味します。 発行後、サーバー、配布プラットフォーム、コンテナー、またはクラウド環境にアプリをデプロイします。 発行プロセスでは、デプロイ用にアプリを準備し、開発環境の外部で使用します。

発行モード

アプリを発行するには、主に 2 つの方法があります。 この決定に影響を与える要因には、デプロイ環境に適切な.NET ランタイムがインストールされているかどうか、およびランタイムをアプリにバンドルする必要がある特定のコンパイル機能が必要かどうかなどがあります。 2 つの公開モードは次のとおりです。

• 自己完結型で公開
  このモードでは、アプリの起動に使用されるプラットフォーム固有の実行可能ファイル、アプリ コードを含むコンパイル済みバイナリ、アプリの依存関係、アプリの実行に必要な.NET ランタイムを含む発行フォルダーが生成されます。 アプリを実行する環境には、.NET ランタイムがプレインストールされている必要はありません。

• フレームワーク依存の発行
  このモードでは、アプリの起動に使用されるオプションのプラットフォーム固有の実行可能ファイル、アプリ コードを含むコンパイル済みバイナリ、およびアプリの依存関係を含む発行フォルダーが生成されます。 アプリを実行する環境には、アプリで使用できるバージョンの .NET ランタイムがインストールされている必要があります。

基本的な発行の方法

プロジェクト ファイルの <TargetFramework> 設定では、アプリを発行するときに既定のターゲット フレームワークを指定します。 ターゲット フレームワークは、任意の有効な ターゲット フレームワーク モニカー (TFM) に変更できます。 たとえば、プロジェクトで <TargetFramework>net9.0</TargetFramework> を使用している場合、.NET 9 をターゲットとするバイナリが作成されます。

複数のフレームワークをターゲットにする場合は、セミコロンで区切って複数の TFM 値に <TargetFrameworks> 設定を設定できます。 アプリをビルドすると、プロジェクトによって定義されたターゲット フレームワークごとにアプリがビルドされます。 ただし、アプリを発行するときは、ターゲット フレームワークを指定する必要があります。

dotnet publish -c Release -f net9.0

ポータブル バイナリ

.NET アプリを発行するときは、特定のプラットフォームをターゲットにするか、ポータブル バイナリを作成できます。 既定では、移植可能なバイナリを作成する場合でも、この動作を明示的に無効にしない限り、.NETはプラットフォーム固有の実行可能ファイル ("apphost") をポータブル DLL と共に発行します。

プラットフォーム固有の実行可能ファイルは、プロパティUseAppHostが既定でtrueとなっているために作成されます。 ポータブル DLL のみを発行し、プラットフォーム固有の実行可能ファイルを除外するには、UseAppHost をfalseに設定し、コマンド ライン (-p:UseAppHost=false) またはプロジェクト プロパティとして使用します。

特定のプラットフォームをターゲットにする利点は、アプリが必要とする 可能性があるネイティブの依存関係 を処理し、ターゲット プラットフォームの特定の要件との互換性を確保できることです。

ネイティブの依存関係

アプリにネイティブの依存関係がある場合、移植可能なバイナリとして公開されている場合は、別のオペレーティング システムで実行されない可能性があります。 たとえば、Windows API に依存するアプリは、macOS または Linux ではネイティブに実行されません。 プラットフォーム固有のコードを提供し、プラットフォームごとに実行可能ファイルをコンパイルする必要があります。

また、参照したライブラリがプラットフォーム固有の依存関係を提供する場合は、アプリがすべてのプラットフォームで実行されない可能性もあります。 ただし、特定のプラットフォームを発行してターゲットにすると、NuGet パッケージのプラットフォーム固有の依存関係が発行フォルダーにコピーされます。

アプリがネイティブの依存関係を使用して発行されるようにするには、特定のプラットフォームに対して発行します。

dotnet publish -c Release -r <RID>

ランタイム識別子の一覧については、 ランタイム識別子 (RID) カタログを参照してください。

クイック リファレンス

次の表は、 dotnet CLI を使用してアプリを発行する方法の簡単な例を示しています。

フレームワーク依存として公開

CLI またはVisual Studioから発行する場合、フレームワーク依存のデプロイは既定のモードです。 このモードでは、アプリの起動に使用できるプラットフォーム固有の実行可能ファイルが作成されます。 プラットフォーム固有の実行可能ファイルの名前は、Windows では myapp.exe に似ているか、他のプラットフォームでは myapp に似ています。

アプリは、特定のバージョンの.NETを対象にするように構成されています。 対象.NETランタイムは、アプリが実行されている環境に存在する必要があります。 たとえば、アプリのターゲットが .NET 9 の場合、アプリを実行する環境には、.NET 9 ランタイムがインストールされている必要があります。

フレームワークに依存するデプロイを発行すると、アプリを実行する環境で使用可能な最新の.NETセキュリティパッチに自動的にロールフォワードするアプリが作成されます。 コンパイル時のバージョン バインディングの詳細については、「使用する.NETバージョンを選択するを参照してください。

利点

• 小規模なデプロイ: アプリとその依存関係のみが分散されます。 アプリを実行する環境には、.NET ランタイムが既にインストールされている必要があります。
• Cross-platform: アプリと.NETベースのライブラリは、他のオペレーティング システムで実行されます。
• 最新の修正プログラムが適用されたランタイムを使用します。アプリは、環境にインストールされている最新のランタイムを使用します。

欠点

• ランタイムを事前にインストールする必要があります: アプリは、ターゲット.NETのバージョンが既に環境にインストールされている場合にのみ実行できます。
• .NETは変更される可能性があります: アプリを実行する環境では、新しい.NETランタイムが使用される可能性があり、アプリの動作が変更される可能性があります。

フレームワークに依存するアプリを起動する

フレームワークに依存するアプリを実行するには、プラットフォーム固有の実行可能ファイル ("apphost") と dotnet myapp.dllの 2 つの方法があります。 dotnet myapp.dllを呼び出す代わりに apphost 実行可能ファイルを直接実行できます。これは、引き続きアプリを実行するための許容可能な方法です。 可能な限り、apphost を使用することをお勧めします。 apphost を使用する利点は多数あります。

• 実行可能ファイルは、標準のネイティブ プラットフォーム実行可能ファイルのように表示されます。
• 実行可能ファイル名はプロセス名に保持されます。つまり、アプリは名前に基づいて簡単に認識できます。
• apphost はネイティブ バイナリであるため、マニフェストなどのネイティブアセットをそれらにアタッチできます。
• Apphost には、セキュリティを強化する低レベルのセキュリティ軽減策が既定で適用されています。 たとえば、制御フロー強制テクノロジ (CET) シャドウ スタックは、既定で .NET 9 以降で有効になっています。 dotnetに適用される軽減策は、サポートされているすべてのランタイムの最小共通分母です。

公開する

dotnet publish -c Release [-r <RID>]

dotnet publish -c Release [-r <RID>] --self-contained false

.NET インストールの検索動作を構成する

既定では、apphost はグローバルにインストールされた .NET ランタイムを検出して使用します。インストール場所はプラットフォームによって異なります。 ランタイムの検出とインストールの場所の詳細については、「 アプリの起動エラーのトラブルシューティング」を参照してください。

.NETランタイム パスは、実行ごとにカスタマイズすることもできます。 DOTNET_ROOT環境変数は、カスタムの場所を指すために使用できます。 すべての DOTNET_ROOT 構成オプションの詳細については、「.NET 環境変数を参照してください。

一般に、 DOTNET_ROOT を使用するベスト プラクティスは次のとおりです。

1. 最初 DOTNET_ROOT 環境変数をクリアします。つまり、テキスト DOTNET_ROOTで始まるすべての環境変数を意味します。
2. ターゲット パスには DOTNET_ROOTを設定し、DOTNET_ROOTのみを設定します。
3. ターゲット apphost を実行します。

.NET 9 以降のバージョンでは、AppHostDotNetSearch プロパティと AppHostRelativeDotNet プロパティを使用して、発行された実行可能ファイルの.NET インストール検索パスを構成できます。

AppHostDotNetSearch では、実行可能ファイルが.NETインストールを検索する 1 つ以上の場所を指定できます。

• AppLocal: アプリの実行可能ファイルのフォルダー
• AppRelative: アプリの実行可能ファイルに対する相対パス
• EnvironmentVariable: DOTNET_ROOT[_<arch>] 環境変数の値
• Global: 登録済み および 既定の グローバル インストール場所

AppHostRelativeDotNetは、AppHostDotNetSearchが含まれているときに検索される実行可能ファイルAppRelative相対パスを指定します。

詳細については、apphost の AppHostDotNetSearch、 AppHostRelativeDotNet、 およびインストール場所のオプションを参照してください。

クロスプラットフォーム DLL のデプロイ

または、プラットフォーム固有の実行可能ファイルを使用せずに、クロスプラットフォーム DLL としてアプリを発行することもできます。 このモードでは、 myapp.dll ファイルが発行出力フォルダーに作成されます。 アプリを実行するには、出力フォルダーに移動し、 dotnet myapp.dll コマンドを使用します。

クロスプラットフォーム DLL として発行するには:

dotnet publish -c Release -p:UseAppHost=false

自己完結型として公開する

自己完結型デプロイ (SCD) を発行すると、発行プロセスによってプラットフォーム固有の実行可能ファイルが作成されます。 SCD の発行には、アプリを実行するために必要なすべての.NET ファイルが含まれますが、.NETのネイティブ依存関係は含まれません。 これらの依存関係は、アプリを実行する前に環境に存在する必要があります。

SCD を発行すると、利用可能な最新の.NETセキュリティパッチにロールフォワードしないアプリが作成されます。 コンパイル時のバージョン バインディングの詳細については、「使用する.NETバージョンを選択するを参照してください。

利点

• Control .NET バージョン: アプリで展開する.NETのバージョンを制御します。
• プラットフォーム固有のターゲット設定: アプリはプラットフォームごとに公開する必要があるため、アプリの実行場所は明確です。

欠点

• 規模の大きい展開: このアプリには.NETランタイムとすべての依存関係が含まれているため、ダウンロードサイズとハードドライブの空き領域は、フレームワーク依存の展開よりも大きくなります。
• .NETバージョンの更新は難しくなります: .NET ランタイムは、新しいバージョンのアプリをリリースすることでのみアップグレードできます。

公開する

dotnet publish -c Release -r <RID> --self-contained true

単一ファイルとして発行する

アプリを単一ファイルのデプロイとして発行すると、アプリケーションに依存するすべてのファイルが 1 つのバイナリにバンドルされます。 このデプロイ モデルは、フレームワークに依存するアプリケーションと自己完結型アプリケーションの両方で使用でき、アプリケーションを 1 つのファイルとしてデプロイおよび配布するための魅力的なオプションを提供します。

単一ファイル アプリは常に OS とアーキテクチャ固有です。 Linux x64、Linux Arm64、Windows x64 など、構成ごとに発行する必要があります。

利点

• 配布の簡略化: アプリケーションを 1 つの実行可能ファイルとしてデプロイして配布します。
• ファイルの煩雑さを軽減: すべての依存関係がバンドルされるため、複数のファイルを管理する必要がなくなります。
• 簡単なデプロイ: 1 つのファイルをコピーしてアプリケーションをデプロイします。

欠点

• ファイル サイズが大きい: 1 つのファイルにすべての依存関係が含まれるため、個々のファイルよりも大きくなります。
• 起動速度が遅い: ファイルは実行時に抽出する必要があり、スタートアップのパフォーマンスに影響を与える可能性があります。
• プラットフォーム固有: ターゲット プラットフォームごとに個別のファイルを発行する必要があります。

単一ファイルのデプロイは、 トリミング や ReadyToRun コンパイル などの他の最適化と組み合わせて、さらに最適化することができます。

単一ファイルの展開の詳細については、「 単一ファイルの展開」を参照してください。

公開する

dotnet publish -c Release -r <RID> -p:PublishSingleFile=true

ネイティブ AOT として発行する

ネイティブ AOT デプロイでは、アプリがネイティブ コードに直接コンパイルされるため、ランタイムが不要になります。 この発行オプションでは 自己完結型の配置 モードが使用されます。コンパイル済みのネイティブ コードには、アプリケーションの実行に必要なすべてのものが含まれている必要があります。 これにより、起動時間が短縮され、メモリ使用量が減りますが、サポートされている機能にいくつかの制限があります。

利点

• 高速スタートアップ: 実行時に JIT コンパイルは必要なく、アプリケーションの起動が高速化されます。
• メモリ使用量: 従来の.NET アプリケーションと比較してメモリ占有領域が低くなります。
• ランタイムの依存関係はありません: ランタイムのインストールを必要とせずにアプリケーション.NET実行されます。
• デプロイ サイズが小さい: 多くの場合、完全なランタイムを使用する 自己完結型のデプロイ よりも小さい。

欠点

• フレームワークのサポートが限定的: .NETのすべての機能やライブラリがネイティブAOTと互換性があるとは限りません。
• ビルド時間が長い: ネイティブ コードへのコンパイルには、通常のビルドよりも長い時間がかかります。
• プラットフォーム固有: ターゲット プラットフォームとアーキテクチャごとに個別にコンパイルする必要があります。
• デバッグの制限: 通常の.NET アプリケーションと比較して、より複雑なデバッグ エクスペリエンス。

ネイティブ AOT のデプロイの詳細については、「 ネイティブ AOT のデプロイ」を参照してください。

公開する

dotnet publish -c Release -r <RID> -p:PublishAot=true

ReadyToRun として発行する

ReadyToRun コンパイルを使用してアプリを発行すると、アプリケーション アセンブリは ReadyToRun (R2R) 形式でコンパイルされます。 R2R は、Just-In-Time (JIT) コンパイラがアプリケーションの読み込み時に実行する必要がある作業量を減らすことで、スタートアップ パフォーマンスを向上させる、事前実行 (AOT) コンパイルの形式です。 この発行オプションは、 フレームワークに依存 する展開モードと 自己完結型 展開モードの両方で使用できます。

ReadyToRun バイナリには、中間言語 (IL) コードと同じコードのネイティブ バージョンの両方が含まれています。 R2R バイナリは通常のアセンブリよりも大きくなりますが、起動パフォーマンスが向上します。

利点

• 起動時間の短縮: アプリの起動時に JIT コンパイラを実行する時間が短縮されました。
• 初回使用時のパフォーマンスの向上: コード パスの初回実行の待機時間が短縮されました。
• 既存のコードと互換性があります: ほとんどの.NETライブラリとフレームワークを変更せずに動作します。
• 柔軟なデプロイ: フレームワークに依存する展開 モードと 自己完結型展開モードの 両方と組み合わせることができます。

欠点

• サイズが大きい: IL コードとネイティブ コードの両方が含まれるため、アプリはディスク上で大きくなります。
• ビルド時間が長い: コンパイルには、標準の発行よりも多くの時間がかかります。
• プラットフォーム固有の最適化: 最適なパフォーマンスの向上には、特定のプラットフォームをターゲットにする必要があります。

公開する

dotnet publish -c Release -r <RID> -p:PublishReadyToRun=true

ReadyToRun のデプロイの詳細については、「 ReadyToRun のコンパイル」を参照してください。

コンテナーのデプロイ

アプリをコンテナーとして発行すると、.NET SDK は、別の Dockerfile を必要とせずに、アプリケーションとその依存関係をコンテナー イメージにパッケージ化します。 このデプロイ モードでは、Docker や Podman などの任意のコンテナー ランタイムで実行できる完全なコンテナー イメージが作成されます。 コンテナーのデプロイでは、Dockerfile を書き込んで保守する必要をなくしながら、最適化された基本イメージを提供することで、コンテナー化プロセスが簡略化されます。

.NET SDK 8.0.200 以降では、コンテナーのサポートは既定で含まれており、追加の NuGet パッケージは必要ありません。 コンソール アプリケーションの場合は、 EnableSdkContainerSupport プロパティを true に設定して、コンテナーのサポートを明示的に有効にする必要がある場合があります。

利点

• 簡略化されたコンテナー化: 基本的なシナリオで Dockerfile を記述または保守する必要はありません。
• 最適化された基本イメージ: Microsoft が提供する最適化された基本イメージと最新のセキュリティ更新プログラムを使用します。
• 一貫性のある環境: 開発、テスト、運用全体で一貫したランタイム環境を確保します。
• 簡単な配布: コンテナー イメージは、さまざまな環境で簡単に共有およびデプロイできます。
• プラットフォームの分離: アプリケーションは分離されたコンテナーで実行され、アプリケーション間の競合が軽減されます。

欠点

• コンテナー ランタイムの依存関係: ターゲット環境にはコンテナー ランタイムがインストールされている必要があります。
• イメージ サイズ: コンテナー イメージは通常、他のデプロイ方法よりも大きくなります。
• 学習曲線: コンテナーの概念とツールを理解する必要があります。
• 制限付きカスタマイズ: 複雑なシナリオでは、カスタム Dockerfile と比較して柔軟性が低くなります。

公開する

dotnet publish -c Release [-r <RID>] /t:PublishContainer

dotnet publish -c Release [-r <RID>] -p:PublishProfile=DefaultContainer

コンテナーのデプロイの詳細については、「.NET SDK コンテナーの作成の概要を参照してください。

こちらもご覧ください

• .NET ランタイム識別子 (RID) カタログ
• 使用する.NETバージョンを選択します
• macOS 用に発行