人に使っていただくソフトを作っていて何が面倒って、2回目以降の配布が一番面倒です。
未来永劫更新不要。。。なんて理想を超えてどころか最近では戯言にもならないので。。。...アンインストールできるだけではなくちゃんと更新できるように作っておくのが、今どきの人に使ってもらうソフトの第1条件になっています。
アプリケーションの更新にはいくつか方法がありますが、まぁいろいろ書くよりスパッと要点だけ。
WiX(3.x)で作成している場合は、ProductCode 部分をちょこっと変えて、MajorUpgrade 要素を入れるだけという手軽さで対応できます。
まずは、MajorUpgrade 要素。この要素があると、アップグレードのための段取りを自動的に組み入れてくれます。リファレンスにはいろいろ書いてありますが、基本的には、DowngradeErrorMessage 属性に”[ProductName] のより新しいバージョンがすでにインストールされています。””古いの引っ張ってきて突っ込もうとかしてんじゃねーよ！” と書いておきます。あ、ちゃんとバージョン管理している(してないわけはないので、つけないわけがないｗｗｗ)場合は、AllowSameVersionUpgrades=”no” もつけておきます。
これでバージョンアップするための下地の半分ができました。次は残りの半分。
WiX 3.x で新規にプロジェクトを作成している場合は、Product 要素のUpgradeCode属性は自動的に設定されているのであまり気にしなくていいですが、アップグレード出来る対象であるという識別のためにUpgradeCode属性には固定的なGUID値が設定されている必要があります。
ここに、ちゃんとそれなりのGUID値がセットされていることを確認します。
基本的にこの2つが設定されてさえいれば、メジャーアップグレード対応は完了です。あとは、リリースするときにはインストーラのバージョンも上げて、ProductCodeを都度変更してやるだけです。
でも、ここまで来たらもう少し手を抜きたいのが人情。どうせどれか一つしか入れないなら、ProductCode だってきっちり管理してなくても問題はないんです。ということで、これも省略してしまいましょう。
WiXでは、GUIDを自動生成することができる場合(できない場所もあります)、”*” としておくことでビルド時に自動生成してくれるという機能を持っています。
これをあらかじめMajorUpgradeで更新するProductのIdにしておけば、ビルド時にチェックするべき個所はVersionだけに絞り込むことができます。
あとは、ビルド時にきちんとバージョン管理を行っておけば(これもTaskを作って自動化することができますが、こちらについては割愛ｗ)、配布の時に面倒なことを考えないで、msi を渡すだけでOKとできます。
ということで、サンプル(抜粋)がこちら。。。
<?xml version="1.0" encoding="UTF-8"?>
<?define ProductVersion="0.00.0518.0"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" UpgradeCode="7C1E0101-0A42-43E4-A7D3-443822B68D61" Version="$(var.ProductVersio)" Name=...>
<MajorUpgrade DowngradeErrorMessage="ちょっ、おまっ！" AllowSameVersionUpgrades="no"/>
</Product>
</Wix>