<! -- Major upgrade -- > <Upgrade Id="$(var.UpgradeCode)"> <UpgradeVersion Minimum="$(var.ProductVersion)" OnlyDetect="yes" Property="NEWERVERSIONDETECTED" /> <UpgradeVersion Minimum="1.0.0" IncludeMinimum="yes" Maximum="$(var.ProductVersion)" IncludeMaximum="no" Property="OLDERVERSIONBEINGUPGRADED" /> </Upgrade> <InstallExecuteSequence> <RemoveExistingProducts After="InstallValidate" /> </InstallExecuteSequence> <Condition Message="!(loc.NewerVersionDetected)"> NOT NEWERVERSIONDETECTED </Condition>
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.|