Thoughts about setup and deployment issues, WiX, XNA, the .NET Framework and Visual Studio
All postings are provided AS IS
with no warranties, and confer no rights. Additionally, views expressed
herein are my own and not those of my employer, Microsoft.
Bob Arnson has been working on some simplifications to the WiX language in WiX v3.5, and he has posted some introductory information about a couple of these changes on his blog. I wanted to link to them here to hopefully help raise visibility for these simplifications:
I have found the major upgrade simplifications to be particularly useful. A while back, I wrote a step-by-step guide for authoring, building and testing major upgrades using WiX, and that guide later got added to the WiX documentation.
As you can see in Bob’s blog post and in the WiX MajorUpgrade element documentation, Bob’s simplifications will allow WiX v3.5 to handle creating the Upgrade table elements, scheduling the RemoveExistingProducts action, and optionally blocking downgrades if a user tries to install an older version of the MSI after installing a newer version. You only need to make sure that you include UpgradeCode and Version attributes in your Product element, and then you can use the new MajorUpgrade element in your WiX v3.5 authoring.
If you choose to, you can continue to use the more verbose syntax described in my previous blog post or the WiX documentation for authoring a major upgrade, but you could instead convert to the new MajorUpgrade element in order to more clearly express the behavior you intend for your MSI and to simplify your setup authoring.
The major upgrade and component authoring functionality described in the above blog posts is available in WiX v3.5 builds starting with the v3.5.1315.0 build on SourceForge, and I encourage you to check them out.
When using the new MajorUpgrade element, is there a property set somewhere that can be evaluated elsewhere? In some situation it is useful to show a limited set of UI dialogs when doing an upgrade, so having the property in the old syntax was useful. Is there something similar I can use when using the MajorUpgrade element?
Hi Alan - The simplified MajorUpgrade element doesn't support this type of scenario. You will need to use the Upgrade and UpgradeVersion elements like Bob shows in the first example in his blog post at www.joyofsetup.com/.../major-upgrades-now-easier-than-ever if you need to set a property that will be used later on in your installation process.
Thanks for the feedback. I took a look at an MSI which implements the MajorUpgrade element using Orca, and noticed a property called WIX_UPGRADE_DETECTED. Do you know if this works in a similar way to the Property attribute specified in an UpgradeVersion? I haven't had a chance to check it out myself, so just wondered if you knew anything about this property and whether it could be used (which would be ideal).
Hi Alan - I looked at the WiX source code, and it will always use the property name WIX_UPGRADE_DETECTED when you use the MajorUpgrade element in your WiX authoring. This property can be used as a condition in other actions in your MSI just like if you set the property in an UpgradeVersion element. I talked a bit with Bob Arnson about this as well, and he believes that it is safe to use this property in this way, and so I'm going to add an item in the WiX documentation to make it "official" for this type of scenario (so that you don't have to rely on undocumented behavior in your installer).
Hi Aaron - Thanks for the update, and cheers for adding it to the documentation, I'm sure it'll help a lot of people out as I couldn't find anything else about this elsewhere.