Windowsアプリ配布方式の知識マップ(知識グラフ)
MSI(Windows Installer)
Windowsの標準インストーラーパッケージ形式。ALLUSERSプロパティなどでインストール先の範囲を選べ、machine-wide installが一般的だがユーザー単位のインストールもできる。
MSIX
package identityを持つ、Windowsのモダンなアプリパッケージング形式。
ClickOnce
.NETのWindowsデスクトップアプリを、利用者単位で簡単に配り、自動更新まで含めて回すための配布技術。マニフェストを中心に配布・更新・キャッシュ管理をまとめて扱う配布モデル。
ClickOnce配布
Windowsサービス
ユーザーのサインインと無関係にバックグラウンドで動くWindowsのプロセス。
サービス
ドライバーパッケージ
デバイスドライバーをシステムへ導入するためのパッケージで、通常のアプリ配布方式とは別問題として扱われる。
デバイスドライバーの導入パッケージ
シェル拡張(エクスプローラー拡張)
右クリックメニューやアイコン表示など、エクスプローラーへ組み込まれる部品。
COM(コンポーネントオブジェクトモデル)
公開インターフェース、レジストリ登録、Apartment Modelなどを土台にした、Windowsのバイナリ互換コンポーネントモデル。
閉域ネットワーク
インターネットに接続せずに運用する隔離されたネットワーク。
オフライン環境
切断環境
package identity
MSIXなどのパッケージが持つ、Windowsが認識する一意の識別子。名前、バージョン、アーキテクチャ、ResourceId、発行元という5つの組で構成される。
パッケージID
コード署名証明書
ソフトウェアの発行元を証明し、改ざんを検出するための証明書。
Authenticode証明書
.NET(Core以降)
.NET Frameworkの後継となる、クロスプラットフォーム対応の.NETランタイム(.NET 5以降)。
モダンな.NET
xcopy配布
レジストリ登録や修復機能、package identityを持たず、フォルダーごとファイルを配置するだけで動作させる配布方式。
xcopyデプロイ
独自updater
署名検証・配信manifest・rollback・チャネル管理などを自社で設計・運用する、独自実装のソフトウェア更新の仕組み。
独自の更新機構
自前updater
全ユーザー向けでWindowsサービスやmachine-wideな設定があるなら、まずMSIを起点に考えるべきというのが本記事の判断表の推奨である
ドライバーが必要な場合、本記事はMSIXではなくMSIか専用インストーラー寄りで考えるべきだとしている
in-process shell extensionが必要な場合、本記事はMSIか専用インストーラー寄りを基本線として挙げている
アプリがCOMコンポーネントの登録を必要とする場合、MSIはそのCOM登録やfile association、machine-wideな設定を伴う導入に利用される。COM登録を伴わないアプリのMSIも多い
閉域・オフライン配布の観点でMSIは比較表でも◎とされ、強い選択肢として挙げられている
MSIXはmodern packagingの中核としてpackage identityの実装を担う
ドライバーとの相性は比較表で×であり、driver packageはMSIXには不向きとされている
in-process shell extensionは基本的にMSIXでは不向きだが、Windows 11 21H2以降ならマニフェスト宣言で条件付きに対応できると本記事は注記している
閉域配布でもMSIXはApp Installerの使い方次第で回るとされている
MSIXの配布ではsigntool.exeなどによる署名が前提となる
ClickOnceは.NETのWindowsデスクトップアプリをper-userで簡単に配布・自動更新するための技術である。.NET Framework時代からある技術で、.NET Framework/.NETのどちらのアプリでも発行できるため、対象は.NET全般であって.NET(Core以降)に限らない
ClickOnceはfile shareやremovable mediaを使えば閉域配布にも使えるとされている
サービスとの相性は比較表で×であり、OSへ深く触るタイプの製品への利用は安全でないとされている
xcopyの弱点としてfile association・service・shell extension・driverが挙げられている
閉域・USB配布・管理者権限なしを優先するならxcopyがいちばん素直だとされている
独自updaterで更新の安全性を担保する設計にするなら、署名検証とそのためのコード署名証明書の運用を自分たちで設計・運用する責任を負うことになる。技術的には署名検証なしでも動作はするが、その場合は改ざんされた更新を検知できない
閉域・オフライン配布の比較表で独自updaterも◎とされている