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

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

発行とは

.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 はポータブル DLL と共にプラットフォーム固有の実行可能ファイルを発行します。

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

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

ネイティブの依存関係

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

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

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

dotnet publish -c Release -r <RID>

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

フレームワークに依存する展開

CLI または Visual Studio から発行する場合、フレームワーク依存のデプロイは既定のモードです。 このモードでは、クロスプラットフォーム アプリをホストするためにプラットフォーム固有の実行可能ホストが作成されます。 ホスト実行可能ファイルのファイル名はプラットフォームによって異なり、 <PROJECT-FILE>.exeのような名前が付けられます。 dotnet <PROJECT-FILE>.dllを呼び出す代わりに、この実行可能ファイルを直接実行できます。これは、引き続きアプリを実行するための許容される方法です。

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

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

利点

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

欠点

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

公開する

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

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

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

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

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

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

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

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

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

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

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

dotnet publish -c Release -p:UseAppHost=false

自己完結型のデプロイ

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

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

利点

• .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 バージョンを選択する