Using the fourth version element on patches

[mlerch]

I'm trying to provide customers continual updates on a product executable which will differ on what we use as the build number - the fourth number, for instance:

10.2.0.1
10.2.0.2
10.2.0.3

When building my patch I get this:

The product version '10.2.0.2' differs from the product version '10.2.0.1' but only past the third element. The Windows Installer does not detect version differences past the third version element.

Is this possible?

[Cary_R]

Hi There,

This should still be possible, but would fall under the category of Small Update Patches. These have to be authored in a specific fashion, targeting only the base release, and using some sort of supersedence mechanism like the 'Minor Upgrade to Target RTM Version' setting in the patch configuration.

I would try this and see if it works for you.

[mlerch]

Hi Cary,

I am targeting only the base release. I turned on the "Minor Update to RTM Version" setting in the Patch configuration.

However I still see the message, and the file is still not getting updated. It gets updated if I change any but the fourth element of the executable version.

Hopefully this is not an msi limitation

thanks,
Mark

[Lurean]

The 4th version field for product version is not supported by the Windows Installer Engine.

http://msdn.microsoft.com/en-us/library/aa370859(VS.85).aspx

this is by design by microsoft.
Microsoft recommneds avoiding small updates and using minor upgrades instead.

http://msdn.microsoft.com/en-us/library/aa370579(VS.85).aspx

[mlerch]

I have been using a minor upgrade, it doesn't work with that. I guess I need to either change the version schema for just our beta or go with a major upgrade, if that will even work.

[#6]

Changing the 4th field of a file should result in the file being upgraded. While MSI doesn't recognize the 4th field of a Product Version, the File Version is compared using a separate set of rules described here:
http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx

What you may be encountering is a small update patch issue, which can occur if the authoring of a small update is, in any way, incorrect. Microsoft suggests using Minor Upgrades because it is very difficult to determine whether a specific Small Update Patch is applied on the system. From a support perspective, this can make the prospect of determining which QFE's are installed on the system challenging. That said, Small Updates do have a place but probably not in the context of several release cycles.

Regardless, you would see the issue with replacing the file described in a log of the installation itself. This would help ensure that you're focused on resolving the correct behavior, though I would personally suggest going the Minor Upgrade Patch route since it will likely be easier to maintain in the long run.

[mlerch]

Well, despite the warning, it is now replacing the file correctly. I don't know why. I do have a minor upgrade item in place, and changed the ProductCode from the original. Perhaps it is going only on the file timestamp.

I'd like to understand why but it's more important that it works. This stuff is confusing when you only do it two weeks out of the year.

thanks,
Mark

[mlerch]

bryanwolf wrote:
Changing the 4th field of a file should result in the file being upgraded. While MSI doesn't recognize the 4th field of a Product Version, the File Version is compared using a separate set of rules described here:
http://msdn.microsoft.com/en-us/library/aa368599(VS.85).aspx

Thank you Bryan, your post came in right after I posted mine. I wish I had known this earlier, I was under the assumption it was requiring the fourth element, due to the warning appearing in IS. I did seem to have an error in how I was designing my patch.

Good stuff - thanks everyone.
Mark