Major upgrades now easier than ever

I’m a fan of major upgrades, which I’ve written about before. For 10 lines of XML, you get free and easy upgrades without having to deal with the costs of patching and minor upgrades:

<!– 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 is a child of the Product element and automatically picks up the UpgradeCode attribute from its parent. That avoids the common duplication of the upgrade code in the Upgrade element.

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.

For details, see the MajorUpgrade element documentation. The feature ships in WiX v3.5.1315.0 and later.

12 thoughts on “Major upgrades now easier than ever”

  2. dB.

    Cool.

    I think that rather than Schedule you should consider implenenting a child node RemoveExistingProducts with Before and After, to be consistent.

  3. Bob Arnson

    dB,

    It’s actually consistent with other “shortcut” authoring, like SetDirectory and SetProperty, in the use of attributes rather than child elements.

    I find unnecessary nesting to be one of the uglier XMLisms. An enumeration is the simplest way of expressing mutually-exclusive choices. It’s more discoverable and makes it impossible to create authoring that’s syntactically correct but semantically invalid (even if the compiler would discover it).

  4. Marais van Zyl

    Bob,

    Just to make things a bit clearer for me.

    In order for major upgrades to properly work, I need to do the following:

    - Set the product Id to *
    - Add the major upgrade section and add a Downgrade message.

    This should be sufficient and should allow major upgrades to happen?

    Thanks!

    Marais

  7. Bob Arnson

    Igor,

    All the language changes are at the WiX level; they don’t affect how MSI itself works, so you still have to follow all of its rules, like for policy files.

  8. Igor

    Thank you for quick answer.
    Then another question:
    I created next component with file which I want to install into GAC (Wix 3.5.1426):

    And I got error message that: file with assembly=”.net” should specify KeyPath=”yes”, but it is only one file in component which should be by default key for that component. Is it an issue or by design?

  9. Igor

    And one more question/issue:
    when I’m using several components with files with the same names (for example, assemblies satellites):

    Then I’m getting warning that the short file name ‘some name’ was generated for multiple files.

    But if I will specify Component Id equal to File Id manually, then this warning is gone.

    It seems to me generation of short file names happens before Component Id equals to resource Id.

  11. Igor

    Thank you!
    Sorry for your distraction.
    I already entered two defects on Wix bug database.

Comments are closed.