Wix toolSetによるWindowsアプリインストーラ作成ガイド

Guide to Creating Windows Application Installers with the WiX Toolset

この記事は１年間全くいいねされない場合、需要が無いと見做し削除されます。

ストックが３つ以上付いた場合に限り、チュートリアル準拠の2章目を執筆します。
この場合でもいいねが全くつかない場合、需要なしと見做します。とても悲しいです。

2026年８月時点において
Wix toolset（最新はWix7）を利用し、WPFアプリ用のインストーラを作成した際の記録です。
VisualStudioでプロジェクトを追加すればよいため、特にWPFしか使えないという事はないです。

前提条件

Wix toolset 7.0(4.0まで後方互換性)、Visual Studio 2026

なぜWixなのか？

Wixは学習曲線が急こう配で、InnoSetUpほどには手軽ではないです。
しかし世はAI時代。十分埋められる勾配だと考えました。
更に最近はUpdateも進み、随分と扱いやすくはなっているそうです。

Wixの利点

WiX Toolset と Inno Setup の比較表
（2026年時点の情報に基づく。将来的な拡張性を重視して整理）

比較項目	WiX Toolset	Inno Setup	備考・将来性への影響
基本の仕組み	XMLで記述 → 本家のWindows Installer (MSI) を生成	Pascal風スクリプトで記述 → 独自EXEインストーラを生成	WiXはOS標準に準拠、Innoは独自エンジン
出力形式	MSI / MSM / MSP / Burn (EXEバンドル)	EXE (ウィザード形式)	MSIは企業展開に強い
学習コスト	高い（Windows Installerの概念理解が必要）	低い〜中程度（スクリプトが直感的）	Innoの方が初心者向き
Visual Studio統合	優秀（HeatWave拡張でプロジェクトテンプレート・インテリセンス）	弱い（外部エディタやコマンドライン中心）	WiXがVS中心開発に有利
カスタムUI	標準UI + BurnでWPF/WinFormsの完全カスタムUI可能	Pascalスクリプトで比較的簡単にカスタム可能（ダークモード対応など）	WiXの方が自由度が高い（特に高度なUI）
カスタムアクション	C# / C++ で本格的に書ける	Pascalスクリプト中心	WiXの方が複雑なロジックに強い
前提条件・バンドル	Burnで強力（.NETランタイムなど複数パッケージを1つにまとめやすい）	手動スクリプトで対応（比較的簡単）	WiXの方が大規模製品向き
企業向け展開	非常に強い（SCCM / Group Policy / サイレントインストール標準対応）	弱い（EXEなので企業ツールとの相性が劣る）	将来的な企業導入を考えるとWiX有利
ファイルサイズ	やや大きめになりやすい	コンパクトになりやすい	-
拡張性・将来性	★★★★★ ・MSI標準なので長期的に安定 ・拡張機能が豊富 ・CI/CD・自動化に強い ・複雑な要件に対応しやすい	★★★☆☆ ・スクリプトで素早く拡張可能 ・シンプルな要件には十分 ・高度な企業要件や標準準拠では限界あり	WiXの方が将来の拡張・企業展開・複雑化に強い
得意なケース	・企業向け配布 ・複雑な依存関係 ・高度なカスタムUI（WPFなど） ・長期メンテナンス	・個人・中小規模アプリ ・素早く簡単に作りたい ・見た目を手軽にカスタムしたい	-
不得意なケース	学習コストが高い・単純な案件にはオーバースペック	MSI必須の企業環境・超複雑なロジック	-

総評

Innoはシンプルな分、拡張性が低いらしくそれは将来的な技術的負債になりえると考えます。

Wixでは特にランタイム同梱※1における優位性（既にインストール済みかを検出）したり、MajorUpgrade機能が強力で重複しにくい堅牢性がある点、独自のUIがXAMLで書ける点を評価しています。

その分、インストールサイズが大きくなりやすいのは問題かもしれません。
学習コストはやはり高いです。

※1　Self-Containdは初回起動が遅い。

準拠するドキュメント

以下に準拠して記述・実際の制作を行います。

Welcome to the team
VisualStudio中心。今回はこちらを準拠
但し画像はなし

Create installers for windows apps using WiX v4
コマンドライン中心なので参考程度。使うときは使うという感じ

Inno SetUp用Link

Inno SetUpは以下を参考にしてください

【Windowsアプリ運用標準】第4章：インストーラ化して運用を自動化する

自作アプリを Inno Setup でインストーラーにする

Sample用Git

本稿ではあくまでもSampleInstallerApplication(Git公開)を対象にしていますが、完成したアプリに対しても全く同じ手順を踏むことになります。やるのは名前を変えることだけです。

第1章 最低限のインストーラを作る

この章までではUIが存在しません。ただのしかばねのようです。

この章を手順７まで読んだ場合に得られる結果

手順1 HeatWave For Visual Studioの導入

HeatWave（ヒートウェーブ）とはFireGiant社が提供する、Visual Studio用の無料拡張機能（Visual Studio Extension） です。

なくてもWix自体は動きますが、Wix3からの変換やプロジェクトtemplate、WiXプロジェクトのネイティブサポートなど、重要な機能を提供してくれます。

意地悪な書き方になりますが、入れたくない人はムリに入れなくいいよという事です。

試しに無効にした際の表示

• 導入方法
  VisualStudioで拡張機能マネージャーを開いて、HeatWaveと検索するだけです。

インストールボタンを押したらVisualStudioを閉じて再起動します。

もしかするとフィッシング詐欺かもしれませんので、キャンセルを押しても構いません。
※OKを押さないともちろんインストールできません。

インストールは比較的短時間で終わるようです。

終わったらVisual Studioを開き直しましょう。インストーラを作成したいプロジェクトを開いてください。

手順2　新しいプロジェクトを追加する

ソリューションエクスプローラーから右クリック。

Wix MSI Packageを選択

プロジェクト名称は任意ですがSampleMSIPackageとします。
他にも追加するので分かりやすいのが望ましいです。

作成されるファイルについて

• ExampleComponents.wxs　：名称は変えても構いません。defaultのコンポーネント設定例です。
  インストールするファイルのプレースホルダー（仮置き） を定義しています。

reference : https://docs.firegiant.com/wix/tutorial/sprint1/spike-explore-examplecomponents/

• Folders.wxs
  HeatWaveのMSI Packageテンプレートに含まれるWiXソースファイルのひとつで、インストール先のフォルダ構造を定義するためのものです。
  HeatWave for visualstudio をインストールする必要がありますが、後述。

reference :　https://docs.firegiant.com/wix/tutorial/sprint1/spike-explore-folders/

→ インストーラがファイルを置くディレクトリ（フォルダ）の階層を宣言する。
→ よく使うディレクトリを1か所にまとめておくことで、重複を避け、後から参照しやすくする。
→ 実際にディスク上にフォルダを「作る」わけではなく、「ここにファイルを入れたい」という場所をMSIに教える役割。

• Package.en-us.wxl
  他言語設定用のファイルです。
  reference : https://docs.firegiant.com/wix/tutorial/sprint1/spike-explore-packageen-uswxl/

• Package.wxl
  HeatWaveのMSI Packageテンプレートで一番重要なメインファイルです。MSIパッケージ全体の「本体」を定義します。

Package.wxl

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
  <Package 
+  Name="..." Manufacturer="..." Version="..." UpgradeCode="...">
+    <MajorUpgrade DowngradeErrorMessage="!(loc.DowngradeError)" />
    <Feature Id="Main">
      <ComponentGroupRef Id="ExampleComponents" />
    </Feature>
  </Package>
</Wix>

• 要素（最重要）
  MSIパッケージそのものを表す要素。
• 主な属性：Name … 製品名（「インストール済みのアプリ」に表示される）
  • Manufacturer … メーカー名（会社名など）
  • Version … バージョン番号（アップグレード判定に使われる）
  • UpgradeCode … GUID。同じ製品の異なるバージョンを関連付けるための識別子

手順3 Package.wxlを編集する

この辺り準拠なのだが、説明不足な箇所は補足する。

2026/8次点の　Package.wxlのtemplate

XML：Package.wxl

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
  <Package Id="TODO_Manufacturer.SampleMSIPackage" Name="SampleMSIPackage" Manufacturer="TODO Manufacturer" Version="1.0.0">
    <MajorUpgrade DowngradeErrorMessage="!(loc.DowngradeError)" />

    <Feature Id="Main">
      <ComponentGroupRef Id="ExampleComponents" />
    </Feature>
  </Package>
</Wix>

各要素について

https://docs.firegiant.com/wix/tutorial/sprint1/spike-explore-package/ も参照

• Id="TODO_Manufacturer.SampleMSIPackage" : TODO_Manufacturerはtemplate側で用意された会社名である。今は気にしないでおくが、変更してもいい。というか普通は変更する。

Id を変えると 「別の製品ファミリー」とみなされ、アップグレードされなくなります（意図的にバージョンを並列インストールしたい場合に使う）。

• Name="SampleMSIPackage"　: アプリケーションの名称

• Manufacturer="TODO Manufacturer" : 前述と同じdefault会社名

WiX は「可能な限り GUID を隠蔽する」方針をさらに進めており、v6 から UpgradeCode の GUID が必須ではなくなりました。v7 でもその方針が継続されています。代わりに人間が読める文字列としてidを使用しています。
　この場合、GUIDは自動生成されます。

尚、GUIDは絶対に手動で変更してはいけないとのことです。
自動生成に任せるべきでしょう。

この時点で発生するエラー

You must accept the Open Source Maintenance Fee (OSMF) EULA to use WiX Toolset v7. For instructions, see https://wixtoolset.org/osmf/
について

URLには <AcceptEula>wix7</AcceptEula>　を使えばいいよと説明されているかと思います。

以下具体的説明

WiX v7 では、バイナリ（NuGetパッケージや wix.exe など）を使う前に、Open Source Maintenance Fee（OSMF）のEULA（利用規約）を明示的に受け入れたことを示す必要があります。これは「利用規約に同意したことを記録する」ための仕組みで、同意していないとビルドが止まります。

ソリューション名をダブルクリックすると以下のように、直接ソリューションファイルを覗くことが出来ます。

ここに先ほどの記述を追加します。

...\SampleInstallerApplication\SampleMSIPackage\SampleMSIPackage.wixproj

<Project Sdk="WixToolset.Sdk/7.0.0">
  <PropertyGroup>
    <AcceptEula>wix7</AcceptEula>
  </PropertyGroup>
</Project>

errorが消えます。

当然ですが、間違った場所に書き込むと動かなくなります。

手順4 Projectをbuildする

「ソリューションエクスプローラー」から[SampleMSIPackage]を右クリック、ビルドします。

出力タブは以下のようになります。（ならない場合はこの記事を最初から読んでエラー原因を探してください）

16:51 でビルドが開始されました...
1>------ ビルド開始: プロジェクト: SampleMSIPackage, 構成: Debug x64 ------
1>  SampleMSIPackage -> C:\TestCode\SampleInstallerApplication\SampleMSIPackage\bin\x64\Debug\en-US\SampleMSIPackage.msi
========== ビルド: 成功 1、失敗 0、最新の状態 0、スキップ 0 ==========
=========== ビルド は 16:51 で完了し、00.222 秒 掛かりました ==========

ここまででできるのは、MSIが作成されるかどうかを確認することだけです。
実際の機能はまだ空のままです。

作成された msiファイル

手順５ プロジェクト参照を追加する

慣れていればさほど難しい事ではないです。

ソリューションエクスプローラーで　SampleMSIPackageを右クリック　→　プロジェクト参照
→　該当のソリューション名を選択するだけです。

VS2026ではProject reference...のままです。

この状態でOKを押すだけです。

手順6 プレースホルダーコンポーネントを置き換える

準拠 : https://docs.firegiant.com/wix/tutorial/sprint2/replace-placeholder-component/

公式ドキュメントは英語圏特有のユーモアに満ちており、要するの微妙に分かりづらくまだるっこしい。しかし愉快な性格ではある。

SampleMSIPackage内で　ExampleComponents.wxs　→　AppComponent.wxs　にリネームする

基本的にはソリューションエクスプローラーを使ってください。
ここにあります

SampleMSIComponents.wxsとした。AppComponentとはこの場合、英語圏特有の表現でYourAppComponentみたいな意味である。

/

SampleMSIComponents.wxs

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
  <Fragment>
    <ComponentGroup Id="SampleMSIInstaller" Directory="INSTALLFOLDER">
      <Component>
+        <File Source="SampleMSIInstaller.exe"/>        <!-- ★ここを変更 -->
      </Component>
    </ComponentGroup>
  </Fragment>
</Wix>

コンポーネントグループの名前を変更したため、そのコンポーネントグループへの参照も変更する必要があります。
Package.wxs　を編集して SampleMSIComponents（変更したい名称）　　元の名称であるExampleComponentsを検索するのも良いです。

Nameは製品名としての名称なので好きなもので良いです。

Package.wxs

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
  <Package Id="TODO_Manufacturer.SampleMSIPackage" Name="SampleMSIPackage" Manufacturer="TODO Manufacturer"
  
  Version="1.0.0">
    <MajorUpgrade DowngradeErrorMessage="!(loc.DowngradeError)" />

    <Feature Id="Main">
+      <ComponentGroupRef Id="SampleMSIComponents" />
    </Feature>
  </Package>
</Wix>

編集したらSampleMSIPackageのビルドを行ってください。

よくあるエラーについて

The identifier 'WixComponentGroup:SampleMSIComponents' could not be found. Ensure you have typed the reference correctly and that all the necessary inputs are provided to the linker.

名前が違うよって出てるだけのエラーです。

SampleMSIComponents.wxsの　<ComponentGroup Id="SampleMSIInstaller.exe"を　一致させるだけです。

Cannot find the File file 'SampleMSIInstaller.exe'. The following paths were checked: SampleMSIInstaller.exe

プロジェクト参照の追加が出来てなくてもこういうerrorが出ます。確認してください、

ここまでで何が可能になったのか？

MSIの作成。

ちなみにreleaseにしました。

C:\TestCode\SampleInstallerApplication\SampleMSIPackage\bin\x64\Release\en-US 内

但し、このままだとUIは一切何もないため実行してもすぐに強制終了されるように見えます。
実際のインストールはされています。

ここまでの流れで、公式ドキュメントのSprint1～4までは殆ど最小限のことしか説明しておらず、あまりにも遠回りな要素が多いため、大半は無視します。どうもそういう方針らしいです。

実際にインストールされたアプリ

C:\Program Files\TODO Manufacturer SampleMSIPackage　に入ってました。

但し、このままだとdllだとか実行に必要なファイルを入れてくれません。

これについて対処します。

手順７ SampleMSIComponents.wxs内でFile要素を指定する

ちなみにドキュメントはこれ https://docs.firegiant.com/wix/schema/wxs/files/

記述例となるタグなどの書式が省略されて相当分かりにくくなっている。
道理で誰も使おうとしないはずである。

SampleMSIComponents.wxs

<Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
  <Fragment>
    <ComponentGroup Id="SampleInstallerApplication" Directory="INSTALLFOLDER">
+      <Files Include="$(var.SampleInstallerApplication.TargetDir)**">
+        <Exclude Files="*.pdb" />
+        <Exclude Files="*.xml" />
      </Files>
    </ComponentGroup>
  </Fragment>
</Wix>

.pdbはエンドユーザーの環境においてデバッグに必要なファイルだったりします。滅多に使わないと思いますが残しておいても良いです。

尚、 <File Source="SampleMSIInstaller.exe"/> <!-- ★ここを変更 -->　
部分は削除します。
<File Source="SampleMSIInstaller.exe"/> <!-- ★ここを変更 -->のみでは　SampleMSIInstaller.exeしかコピーされません。

このようにすることで、自動的にほぼ全てのファイルがインストールフォルダに移されます。

Sampleアプリケーションが実行可能になりました。

第2章　WixインストーラのUI

時間が掛かるのでストック3以上で追記。