Reputation: 61
For internal reasons our current version was set to 901.0.1500.0, our project is a C# .NET one and uses installShield for installation, patch creation, upgrades etc... During our testing it all worked fine but we did recently came across several articles (mostly pretty old ones) that state that the version numbers of a.b.c.d must follow the rule that a and b must be smaller than 255. Again, we haven't encountered any issues during our testing but that made us a little worried.
Can anyone assist in clearing this out ?
Thanks a lot.
Upvotes: 5
Views: 1360
Reputation: 15905
There are three kinds of versions that one encounters in a Windows Installer Package:
ProductVersion
property, and due to a compressed copy of it being stored as a DWORD in the registry to support Major Upgrades, it must be in the format of up to 255.255.65535.x
(where x
is ignored for version comparisons) in order to work correctly.Version
column of the File table. The two are compared as part of File Versioning Rules to determine whether a given file replaces another or has already been replaced. They typically will correctly compare versions up to 65535.65535.65535.65535.I think you're talking about the first case. The problem you can encounter is that the version comparisons done to see if a given installed product is in the version range described in the Upgrade table is done with the DWORD representation. When a major version such as 901 is smashed into a single byte, it will overflow in ways that are hard to predict and leverage. Odds are good it will act similarly to a major version of 103, and may otherwise work out. However a large number in the minor version slot may impact the value seen as the major version.
See Installshield 2011 - Problem Upgrading existing software with Version format 2009.727.1365 for an example of the possible fallout.
Upvotes: 8