<!– Major upgrade –>
<UpgradeVersion Minimum="$(var.ProductVersion)" OnlyDetect="yes" Property="NEWERVERSIONDETECTED" />
<UpgradeVersion Minimum="1.0.0" IncludeMinimum="yes" Maximum="$(var.ProductVersion)" IncludeMaximum="no" Property="OLDERVERSIONBEINGUPGRADED" />
<RemoveExistingProducts After="InstallValidate" />
Easy enough to cut and paste but it isn’t exactly what I would call expressive—the intent behind the code isn’t obvious, though it can be deduced fairly easily.
WiX can do better.
So, like the last time I tweaked the WiX language, it’s time for a new feature: The MajorUpgrade element encapsulates the most common options for major upgrades and creates the appropriate rows in the Upgrade and LaunchCondition tables and provides a simpler way of specifying the scheduling of the RemoveExistingProducts action. For example, here’s the simplest use:
<MajorUpgrade DowngradeErrorMessage="Can’t downgrade." />
Downgrades are blocked by default, which requires you to specify a message for the launch condition message.
MajorUpgrade has the following attributes:
|AllowDowngrades||Downgrades are blocked by default.|
|DowngradeErrorMessage||The launch condition message displayed when a downgrade is detected.|
|IgnoreRemoveFailure||Uninstall failures are upgrade failures by default.|
|MigrateFeatures||Manual control over the features installed in the newer product.|
|RemoveFeatures||Manual control over the features removed from the older product.|
|Schedule||When to schedule the RemoveExistingProducts action.|