August 27, 2010

WiX-Users: Exceeding Version Limits

Sohail Somani recently asked on the WiX-Users List:

I'm currently in the middle (or nearing the end, I hope) of porting an installer from the evil that shall not be named to WiX.


Mostly, it's been pretty easy. However, one thing which is sticking out is the version number. The products being ported use the current year as the major version number and this means strings like "2011.foo.bar".


...Is there a  simpler way to exceed the limits...? 

The tool ( let me guess: InstallShield ) Sohail used to use isn't the evil, it's how it was used that is incorrect. Over my many years of writing installs I've seen this situation happen over and over:

(I'll use one real world example to illustrate how absurd this really can get when you let functionals try to drive the decision without consulting technical resources. Seriously.... don't ask )

Release Manager:  I need the product version to be  DMLSS_V3.00.01.A.01.10
Setup Developer: I am sorry, I can only do x.x.x.x with certain upper and lower bounds for each field.
Release Manager:  That's crazy, the install shouldn't dictate what I choose.  You must make it what I say.

However, certain the release manager is about how things must be done to meet his 'special' business needs ( aren't they always? ), the MSI SDK is quite clear on the definition of the ProductVersion property:

The format of the string is as follows:

major.minor.build
The first field is the major version and has a maximum value of 255. The second field is the minor version and has a maximum value of 255. The third field is called the build version or the update version and has a maximum value of 65,535.
The old tool allowed this violation ( usually without much real life harm, perhaps some problems doing Major Upgrades ) but WiX simply doesn't allow it.  I think that's a good thing because it helps the install developer when he needs to tell management:

Setup Developer: I'm sorry, I can display your custom version scheme on the dialog but I cannot possibly assign it to the ProductVersion.

Instead it looks like Sohail is just looking for a way around MSI to make the release manager happy.  I understand that pressure but personally I never tolerate it.  I suppose that's partly why I change jobs so often.    Still, it can get better as evidenced by the fact that I've been at my current employer for nearly two years now when the last time I worked for them I barely made it past a year.    Push back hard enough and provide sound reasoning and eventually it will improve.

6 comments:

Anonymous said...

Preach on brotha!
A company I used to work at insisted that the installer's major.minor.patch.build lined up with our build system. They were then surprised when they would spin a new build of v3.2.3 and the installer would complain that this version is already installed.

"v3.2.0 to v3.2.3 works fine, why can't we go straight from 3.2.3.23 to 3.2.3.65?!?"

No amount of pointing to the MSI documentation or pitching the idea that the installer version doesn't necessarily have to line up with the product version would convince release management otherwise.

Let's change the standard to conform to our schemes instead of compromising and adjusting our schemes to align better with standards.

Setup/Install is still an afterthought.

Jesse said...

Weird, I just ran in to this, and I'm kind of looking for help.

I'm trying to do an upgrade from an install that had 310 as the second version number, and my current install doesn't trigger the major upgrade properly because of it.

I'd really rather not force a pre-uninstall, but it's starting to look like that's what's going to happen.

Christopher Painter said...

The problem is FindRelatedProducts is very picky about how it searches for products and your 310 falls outside of the allowable range of 0 - 255.

Here's the workaround: look at your Upgrade row and get the name of your ACTION Property. Next get the ProductCode for your 310 build.

Now write a Type 51 Set Property custom action that assings that ProductCode to your ActionProperty on the condition that your ActionPropety is currently empty.

Schedule the custom action right after FindRelatedProperties.

Now RemoveExistingProducts will have an ProductCode to work with and remove your old install.

Jesse said...

Ah, that worked. Thanks a ton.

Now that you've pointed it out, it makes since how all of that works. It's a difficult thing to kind of "discover" on your own though.

Christopher Painter said...

The Windows Installer SDK is a great source for the information despite the fact that it's a horrible read. You pretty much have to be dedicated and read it topic by topic repeatedly until it starts to make sense.

ClintCambier1988 said...

Even though this is an old post and it's WiX instead of Installshield I'd like to add my two cents.
I am creating an Installshield 2012 Spring project and I had the same issue.
Our previous installers had a Product Version in the format 2005.xx.xxxx. Obviously this 2005 was an issue.

Instead of setting the ISACTIONPROP1 property to any value (as mentioned in http://community.flexerasoftware.com/showthread.php?195076-Old-Product-version-in-2009-727-1365-format).
I added a major upgrade item with the following values:

Product code of the old installers: xxx (enter yours here)
Minimum version: 2005.001.0001
Maximum version: 2005.255.65535
Version Range Inclusive (might be overkill)

Apparently, the system does allow the 2005.xxx.xxxx format here. It detected and removed the previous installation.