A lot is side in the MSI SDK about servicing strategies. Much of it is confusing and has to do with the intricate details of Major vs Minor vs Small Upgrades and Upgrades shipped as MSI's or as Patches. The UpgradeCode property itself is defined as a "GUID representing a related set of products".
If you do this all correctly you get a nice user experience. For example I might install one version of a text editor and then later upgrade to the latest version of the text editor.
But what really isn't mentioned in the SDK is what to do when you have a related product but you don't want to do an upgrade. Perhaps what you really want is a side by side installation of a new version of a product.
For example, how you feel if you installed Visual Studio 2008 and then when you installed Visual Studio 2010 it remove Visual Studio 2008? What if you insalled InstallShield 12 and when you installed InstallShield 2011 it removed InstallShield 12?
Would you really be ok with that? I wouldn't. I couldn't possibly move all of my software baselines to a newer tool or have 2 machines on my desktop for the two different sets of tools.
These are times when you must design both your application and your installer to be able to support side by side installations of different versions of the software.
Sadly, the WiX team has made this choice for me. Rather then support Votive 3.0 and Votive 3.5 side by side installations with Visual Studio 2008 and Votive 3.5 with Visual Studio 2010 they have chosen to do a Major Upgrade and support only Votive 3.5 on Visual Studio 2008 and Visual Studio 2010.
To make it even more interesting they have broken backwards compatibly by changing the name of the MSBuild Targets file that the .wixproj points to.
Basically the software was designed that if you want to use Votive 3.5, you gotta be all in.
Well, perhaps some people will be ok with that. If you are new to WiX without a huge previous investment or you don't use Votive perhaps you will be ok also. However, for the massive environment that keeps me busy at my day job I say:
Pass
I make this call because WiX 3.5 only brings marginal benefit to my situation while requiring me to make a substantial commitment with a lot of associated risk.
It's obviously too late to fix this for 3.5 as this would be the sort of high risk last minute activity that any setup developer hates. However I hope to see a different story for 3.6. I'd like to be able to have the latest 3.5 installed on my personal machine at home while also installing the latest 3.6 weekly release. When 3.6 goes RTM one day I hope to have 3.5 and 3.6 installed side by side.
As an aside, Industrial Strength Windows Installer XML will work with any combination of Visual Studio 2008, 2010 or None and Windows Installer XML 3.0, 3.5, 3.6 or none. IsWiX technically just authors XML files so it has no physical dependencies on either VS or WiX other then a shared understanding of the wix.xsd file.
I completely agree with you Christopher! It's been a painful upgrade path from WiX 3.0 to 3.5, not because the upgrade itself is difficult, but for the simple reason that we can't have them sitting side-by-side.
ReplyDeleteThe real kicker was on our build server, we have products released in WiX 3.0 using Visual Studio 2008 that need upgrades, but our trunk had moved to Visual Studio 2010 so developers had to move to WiX 3.5. Too bad if you need to support both!
I'm sure they had valid reasons for not supporting 3.0 and 3.5 concurrently, but I too really hope the WiX team allow 3.5 and 3.6 to sit side-by-side.