Windowsインストーラ作成に、WiXSharpという選択肢もありますよ（ただしWiX Toolsetが使える人限定）

# 概要

Windowsインストーラを作ろうとした場合に、WiX Toolsetという有力な選択肢があります。そのWiX Toolsetをさらに作りやすくするWiXSharpというライブラリがあります。

しかしこのWiXSharpはなかなか癖が強く、前提条件がピタリはまると大きな力を発揮しますが、外れているとかえって苦労を呼ぶ場合があります。そのメリット・デメリットや、どういう人に向いているかというところを私の考えでまとめます。

# 最初に結論まとめ

```plantuml
@startuml

start
if (WiXを触ったことが) then (ない)
    :お勧めしない。WiXも同時に勉強する覚悟が必要;
    end
else (ある)
endif

if (次の案件に画面作成が必要？) then (YES)
    :WiXの画面作成が面倒なら、採用お勧め;
    end
else (NO)
endif

if (WiX（msi）の製品コードやモジュールの書き方に不満は) then (有る)
    :採用お勧め;
    end
else (特にない)
    :WiXで十分かも？使っても良いがメリットが薄い;
    end
endif

@enduml
```

# 説明

※WiX ToolsetをWiX、Windowsインストーラをmsiと略記します

msiを本気で作ろうとすると、やはり最初に選択肢に挙がるのはInstallShieldでしょう。しかし同時に、「ライセンス料が高いので、もっと安く作れないか」という話が必ず挙がると思います。VisualStudioにもちょくちょくとインストーラ作成機能が入っては消えていますが、ただモジュールを入れるだけではなく複雑な処理をしようとすると力不足です。

そこで次に挙がってくる選択肢は、やはり[WiX Toolset](https://wixtoolset.org)ではないでしょうか。素で作るには厄介すぎるmsiを、C#と独自のXMLをベースとしてかなり作りやすくしてくれるものです。しかし、それでもまだ「画面が作りづらい」「msi独自の定義が理解しづらい」などの問題は残ります。

これを解決するもう一つの選択肢に、[WiXSharp](https://github.com/oleg-shilo/wixsharp)があります。しかし、概要にも書いたようになかなか厄介なので、それについて説明していきます。

# メリット・デメリット

まず、メリットとデメリットをざっくりまとめます。その後に、詳しく説明してきます。

## メリット

 1. msiの画面を、WPF（xaml）で作成できる（XML的なmsi独自の何かではなく！）
 1. msiの全ての宣言をC#上で行うので、C#で実装を統一できる。カスタムアクションとの定義の共通化などがやりやすい
 1. msiの「そうはならんやろ」と皆が思っていたところを、いくつかラッピングして改善している

 ## デメリット

 1. msi、WiXの十分な知識があった上で、さらにWixSharpを学ぶ必要がある
 1. 完成されたライブラリというよりは、半完成品の製作キットという感じ

# 詳しく説明

## メリット：msiの画面を、WPF（xaml）で作成できる

これは最大のメリットだと思います。WiXであっても、画面作成については画面を定義しているmsiのXMLをカスタマイズするような形で作る必要があって、専用のスキルが必要です。

その画面を、WPFで作ることができます。最初からCaliburn.Microが入っていて、MVVMやDIなども軽くなら使うことができます。これはつまり、Windowsアプリケーションを作っているスキルさえあれば、msiの画面を作る新たなスキルが必要ないという事です。インストーラは作ったアプリをインストールするためのものであり、インストーラのために新技術を習得するのは無駄が多いので、これはかなり助かります。

## メリット：C#で実装を統一できる

WiXの場合はXMLで定義するような内容も、WiXSharpでは全てC#で定義できます。インストールするモジュールの一覧、バージョン、などの定義もC#であるため、これを例えばinternal staticのフィールドとして宣言しておけば、C#のカスタムアクションで同じ定義を使うこともできます。特にカスタムアクションで色々なことをやっている場合、これによるメリットが大きいと思います。

## メリット：msiの不満点をいくつかラッピングして改善している

msiには、いまいち理解に苦しむところがいくつかあります。例えば、普通の開発者がイメージする「アップデート」を行うには、「ProductCode」を変更する必要があります。アップデートすると製品コードが変わる。直観的にピンと来ません。

そういったところを、C#のインターフェースに変えるに当たって、多少ラッピングして分かりやすくしています。もちろんmsiにも言い分は有ると思いますし賛否有ると思いますが、割と皆が思っていたことを反映してくれているように思います。

## デメリット：msi、WiXの十分な知識があった上で、さらにWixSharpを学ぶ必要がある

一見した印象では、msi、WiXを隠蔽して使いやすくしたライブラリのように見えます。しかし、そうではありません。

あくまで、それらをC#で扱うためのアダプタを提供するものです。なので、WiXの何のアダプタなのかを理解して使わないと上手く行きません。何か調べ物をすると、「そのプロパティはWiXのこのXMLと同じだから、WiXのこの属性を設定すれば良いよ」みたいな、WiX知識前提の話が平気で出てきます。

ドキュメントもそういう感じで、「WiXと同名の定義については説明を省略する。独自の部分について説明する」というスタンスなので、そもそもWiXを知らないと説明が理解できません。

WPFについても同様で、「WPFのUserControlとして書けるようにして、共通インターフェースからこれらの情報を渡す仕組みを作った。それだけあれば、WPF使いなら分かるな？後は好きにやってくれ」という感じのスタンスです。WPFを知らない人は付いていけません。

## デメリット：半完成品の製作キットという感じ

「インターフェースがきっちり決まっていて、中はブラックボックス」といった感じのライブラリではありません。何かサンプルと違うことをやろうとすると、構造を理解してカスタマイズするつもりで挑む必要があります。

例えば・・・NuGetでライブラリを追加するとカスタムアクション内で使用できますが、実行するとそのDLLがロードできません。
これは、WiXSharpのカスタムアクションは一時フォルダに展開して実行するという仕組みであるため、そこにDLLを持ち込む必要がある事を前提として理解する必要があります。それを理解していれば、NuGetのビルド出力をmsiに取り込む定義を足すことで、問題を解決できることが分かるはずです。といった具合です。


# つまり、どういう人に向いているか

次のような人には向いていません。

 * × C#使いが初めてWindowsインストーラを作るが、何を使うのが良いか？一番いいのを頼む

そういう人がどうしてもWPFで画面を作りたい場合は、相当の覚悟をして採用する必要があります。WPFの画面にこだわりがなければ、まずは素のWiXを使ってみた方が良いと思います。

次のような人ならピタリとはまりますし、かなりのメリットを得られると思います。

 * ○ WiXでインストーラを作ったことはあるが、面倒な点があった。今度作るインストーラはもっと楽に作りたい

# まとめ

率直なところ、WiXSharpはよく考えずに触るとかなり痛い目を見る初見殺しのライブラリという印象はあります。しかし、WiX・msi・WPFなどをよく理解している人が適切なケースで使うと、かなりの力を発揮します。これから取り組むプロジェクトに合うかどうかを慎重に検討した方が良いですが、使える場合はぜひ使ってみましょう。