WiXインストーラーアップグレードの実装方法
職場では、インストールパッケージのビルドに WiX を使用します。製品Xをインストールすると、そのマシンでその製品の以前のバージョンがアンインストールされるようになります。
インターネット上のいくつかの場所でメジャーアップグレードについて読んだことがありますが、機能しませんでした。誰でも、以前のバージョンのアンインストール機能をWiXに追加するために必要な手順を正確に指定できますか？
最新バージョン（3.5.1315.0ベータ版）では、独自のバージョンを使用する代わりに MajorUpgrade要素 を使用できます。
たとえば、このコードを使用して自動アップグレードを実行します。ダウングレードを防ぎ、ローカライズされたエラーメッセージを表示し、既存の同一バージョンのアップグレードも防ぎます（つまり、下位バージョンのみがアップグレードされます）。
<MajorUpgrade
AllowDowngrades="no" DowngradeErrorMessage="!(loc.NewerVersionInstalled)"
AllowSameVersionUpgrades="no"
/>
最後に、私は解決策を見つけました-同じ問題を抱えている可能性のある他の人（5人全員）のためにここに投稿しています：
- 製品IDを*に変更します
製品の下に以下を追加します。
<Property Id="PREVIOUSVERSIONSINSTALLED" Secure="yes" /> <Upgrade Id="YOUR_GUID"> <UpgradeVersion Minimum="1.0.0.0" Maximum="99.0.0.0" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="yes" IncludeMaximum="no" /> </Upgrade>InstallExecuteSequenceの下に以下を追加します。
<RemoveExistingProducts Before="InstallInitialize" />
これから、製品をインストールするたびに、以前にインストールされたバージョンが削除されました。
注：アップグレードIDを独自のGUIDに置き換えます
以下は、メジャーアップグレードに使用する構文の種類です。
<Product Id="*" UpgradeCode="PUT-GUID-HERE" Version="$(var.ProductVersion)">
<Upgrade Id="PUT-GUID-HERE">
<UpgradeVersion OnlyDetect="yes" Minimum="$(var.ProductVersion)" Property="NEWERVERSIONDETECTED" IncludeMinimum="no" />
<UpgradeVersion OnlyDetect="no" Maximum="$(var.ProductVersion)" Property="OLDERVERSIONBEINGUPGRADED" IncludeMaximum="no" />
</Upgrade>
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>
@Brian Gillespieが指摘したように、必要な最適化に応じてRemoveExistingProductsをスケジュールする場所は他にもあります。 PUT-GUID-HEREは同一でなければなりません。
Product要素内のUpgrade要素は、アクションの適切なスケジューリングと組み合わされて、目的のアンインストールを実行します。削除するすべての製品のアップグレードコードを必ずリストしてください。
<Property Id="PREVIOUSVERSIONSINSTALLED" Secure="yes" />
<Upgrade Id="00000000-0000-0000-0000-000000000000">
<UpgradeVersion Minimum="1.0.0.0" Maximum="1.0.5.0" Property="PREVIOUSVERSIONSINSTALLED" IncludeMinimum="yes" IncludeMaximum="no" />
</Upgrade>
ビルドに注意すれば、人々が誤って古いバージョンの製品を新しいバージョンの上にインストールするのを防ぐことができます。それが最大フィールドの目的です。インストーラーをビルドするとき、UpgradeVersion Maximumをビルドするバージョンに設定しますが、このシナリオを防ぐためにIncludeMaximum = "no"を設定します。
RemoveExistingProductsのスケジューリングに関する選択肢があります。私はInstallFinalizeの後に（他の人が推奨しているInstallInitializeの後にではなく）スケジューリングすることを好みます：
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallFinalize"></RemoveExistingProducts>
</InstallExecuteSequence>
これにより、新しいファイルとレジストリキーがコピーされるまで、製品の以前のバージョンがインストールされたままになります。これにより、古いバージョンから新しいバージョンにデータを移行できます（たとえば、ユーザー設定のストレージをレジストリからXMLファイルに切り替えましたが、丁寧に設定を移行したい場合）。この移行は、InstallFinalizeの直前に遅延カスタムアクションで実行されます。
もう1つの利点は効率です。変更されていないファイルがある場合、InstallFinalizeの後にスケジュールするときに、Windowsインストーラーがそれらのファイルを再度コピーすることはありません。 InstallInitializeの後にスケジュールを設定すると、以前のバージョンが完全に削除されてから、新しいバージョンがインストールされます。これにより、ファイルが不必要に削除され、再コピーされます。
他のスケジュールオプションについては、MSDNのRemoveExistingProductsヘルプトピックを参照してください。今週のリンクは http://msdn.Microsoft.com/en-us/library/aa371197.aspx
WiX-usersメーリングリスト でこれを尋ねる方が良いかもしれません。
WiXは、Windowsインストーラーの動作を十分に理解したうえで使用するのが最適です。 「 Windowsインストーラーの決定版ガイド 」の取得を検討してください。
既存の製品を削除するアクションは、 RemoveExistingProductsアクション です。それが何をするかの結果は、それがスケジュールされている場所、すなわち、障害が古い製品を再インストールするかどうか、そして変更されていないファイルが再びコピーされるかどうかに依存するからです。
RemoveExistingProductsは、現在のインストールの<Upgrade>要素を処理し、@Id属性を、インストールされているすべての製品のUpgradeCode（<Product>要素で指定）に一致させます。システム。 UpgradeCodeは、関連製品のファミリを定義します。このUpgradeCodeがあり、バージョンが指定された範囲内にあり、UpgradeVersion/@OnlyDetect属性がno（または省略されている）である製品はすべて削除されます。
RemoveExistingProductsのドキュメントには、UPGRADINGPRODUCTCODEプロパティの設定が記載されています。これは、アンインストールプロセス削除される製品の場合がそのプロパティを受け取り、その値がインストールされる製品のProduct/@Idであることを意味します。
元のインストールにUpgradeCodeが含まれていなかった場合、この機能は使用できません。
このサイトを使用して、WiXアップグレードの基本を理解しました。
http://wix.tramontana.co.hu/tutorial/upgrades-and-modularization
その後、サンプルインストーラーを作成し（テストファイルをインストール）、アップグレードインストーラーを作成しました（2つのサンプルテストファイルをインストールしました）。これにより、メカニズムの仕組みを基本的に理解できます。
そして、マイクがApressの本「Windowsインストーラーの決定版ガイド」で述べたように、理解するのに役立ちますが、WiXを使用して書かれているわけではありません。
とても便利だった別のサイトは次のとおりです。
WiX のドキュメントを読み、サンプルをダウンロードしましたが、アップグレードにはまだ多くの問題がありました。マイナーアップグレードは、それらのアンインストールを指定する可能性があるにもかかわらず、以前の製品のアンインストールを実行しません。調査に1日以上費やしましたが、WiX 3.5がアップグレード用の新しいタグを導入したことがわかりました。使用方法は次のとおりです。
<MajorUpgrade Schedule="afterInstallInitialize"
DowngradeErrorMessage="A later version of [ProductName] is already installed. Setup will now exit."
AllowDowngrades="no" />
しかし、主な理由は、ドキュメントが「REINSTALL = ALL REINSTALLMODE = vomus "マイナーおよびスモールアップグレード用のパラメーターですが、それらのパラメーターがメジャーアップグレード用にFORBIDDENであるとは言いません-単に停止しますワーキング。したがって、メジャーアップグレードでそれらを使用しないでください。
Alex Shevchukのチュートリアルをご覧になることをお勧めします。 MSIからWiXへ、パート8-メジャーアップグレード で実践的な例を使用して、WiXによる「メジャーアップグレード」について説明します。
しばらくチュートリアルから逃した重要なことの1つ（ http://www.tramontana.co.hu/wix/lesson4.php から盗まれたもの）は、「この製品の別のバージョンは既にインストール済み」エラー：
*小さなアップデートは、1つまたはいくつかのファイルへの小さな変更を意味し、変更は製品バージョンの変更を保証しない（メジャー.minor.build）。製品GUIDを変更する必要もありません。何らかの点で以前のものとは異なる新しい.msiファイルを作成するときは、常にパッケージGUIDを変更する必要があることに注意してください。インストーラーは、インストールされたプログラムを追跡し、ユーザーがこれらのGUIDを使用してインストールを変更または削除するときにそれらを見つけます。異なるパッケージに同じGUIDを使用すると、インストーラーが混乱します。
マイナーアップグレード製品バージョンがすでに変更されている箇所の変更を示します。 ProductタグのVersion属性を変更します。製品は同じままであるため、製品GUIDを変更する必要はありませんが、もちろん、新しいパッケージGUIDを取得します。
メジャーアップグレードあるフルバージョンから別のバージョンへの移行などの重要な変更を示します。すべてを変更：バージョン属性、製品およびパッケージのGUID
WiXの最新バージョン（3.0）を使用していますが、上記の機能を使用できませんでした。しかし、これはうまくいきました：
<Product Id="*" UpgradeCode="PUT-GUID-HERE" ... >
<Upgrade Id="PUT-GUID-HERE">
<UpgradeVersion OnlyDetect="no" Property="PREVIOUSFOUND"
Minimum="1.0.0.0" IncludeMinimum="yes"
Maximum="99.0.0.0" IncludeMaximum="no" />
</Upgrade>
PUT-GUID-HEREは、製品のUpgradeCodeプロパティで定義したGUIDと同じである必要があることに注意してください。
以下は私のために働いた。
<Product Id="*" Name="XXXInstaller" Language="1033" Version="1.0.0.0"
Manufacturer="XXXX" UpgradeCode="YOUR_GUID_HERE">
<Package InstallerVersion="xxx" Compressed="yes"/>
<Upgrade Id="YOUR_GUID_HERE">
<UpgradeVersion Property="REMOVINGTHEOLDVERSION" Minimum="1.0.0.0"
RemoveFeatures="ALL" />
</Upgrade>
<InstallExecuteSequence>
<RemoveExistingProducts After="InstallInitialize" />
</InstallExecuteSequence>
製品のUpgradeCodeがアップグレードのIDと一致していることを確認してください。
これは、メジャーDOWN gradeであっても、私にとってはうまくいったものです：
<Wix ...>
<Product ...>
<Property Id="REINSTALLMODE" Value="amus" />
<MajorUpgrade AllowDowngrades="yes" />