.NET Core アプリケーションの配置についてのメモ
参照元:.NET Core application deployment
参考：主に技術日記 / .NET Coreが動くまで
.NET Coreアプリの配置の種類
Framework-dependent deploymentFDD
配置対象となるシステム(マシン)にインストールされている.NET Coreのバージョンに依存して、モジュール配置を行う方式。
.NET Coreアプリは、基本的に.NET Coreがインストールされているいずれのマシンでも実行可能です。
そのため、FDDによる配置では .NET Coreを除いた 実行のために必要な自身のモジュールやサードパーティのモジュールのみで構成します。
FDDに含まれるDLLファイルは、コマンドラインからdotnetユーティリティを使用して起動します。
dotnetコマンドラインは、アプリのランチャーとして機能し、指定されたパラメータに対応するdllをCorRunにホストして実行します。
（例：dotnet app.dll）
CoreRun Hostは、Hosting APIを使用したマネージコードのJIT, GCといったランタイムやAppDomainの生成、およびマネージコードのエントリーポイントからの起動などを行います。
CoreRun Hostでは、プラットフォーム毎に用意されており、この機構によりプラットフォーム毎の差異を吸収します。
どのような場合にFDDを作成するか
- ターゲットとなるOSを特定しない.NET Coreアプリを作成したい場合。
- 配置用パッケージ全体のサイズを小さくしたい場合。
- 対象システムで、同じ.NET Coreを使用しているアプリがインストールされている場合
FDDのデメリット
- 特定の.NET Coreのバージョンをターゲットとしたアプリの場合、最新バージョンのインストールなどが行えなくなる
- 可能性は低いが、.NET Coreランタイムやライブラリで使用していた機能が将来バージョンで振る舞いの変更が行われた場合、アプリの振る舞いが変更になる
Self-contained deploymentSCD
FDDとは異なって、対象となるシステム（マシン）のコンポーネントに依存しない方式です。実行に必要となる.NET Coreライブラリや.NET Coreランタイムは保持し、他の.NET Coreアプリケーションと分離します。
SCDは、プラットフォーム毎の実行ファイル（例：appというアプリケーションの場合、Windowsであればapp.exeというような形式）が含まれており、app.dllがRenameされて含まれる。
どのような場合にSCDを作成するか
- 自身のアプリに使用する .NET Core のバージョンを制御したい場合。 SCDで構成すると、必要モジュールがすべて組み込まれるため、環境に依存しないアプリの作成が可能。
- 対象となるシステム（マシン）で .NET Coreアプリが確実に動作する保障が必要な場合。
SCDのデメリット
- SCDは自動生成されないため、ビルドの際にターゲットプラットフォームの設定やSCDへの切り替えなどの追加設定を行う必要がある
- .NET Coreのモジュールも含まれるため、配布用パッケージのファイルサイズが多きくなる
- １つのマシンに複数のSCDアプリを配置すると、重複したファイルによってディスクスペースが消費される。