This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Version field limitations
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 04, 2010
02:48 PM
4 digits version number
When creating a new Basic MSI Project we set up version numbers as follow:
yyyy.mm.000x, Ex. 2010.09.0001 but when we go to the Application Information and set the version number as above we get an error message:
Invalid version entered.
The version number must contain only number and must be in the format aaa.bbb.ccccc or aaa.bbb.ccccc.ddddd
yyyy.mm.000x, Ex. 2010.09.0001 but when we go to the Application Information and set the version number as above we get an error message:
Invalid version entered.
The version number must contain only number and must be in the format aaa.bbb.ccccc or aaa.bbb.ccccc.ddddd
(9) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 05, 2010
01:43 AM
PepeTa wrote:
When creating a new Basic MSI Project we set up version numbers as follow:
yyyy.mm.000x, Ex. 2010.09.0001 but when we go to the Application Information and set the version number as above we get an error message:
Invalid version entered.
The version number must contain only number and must be in the format aaa.bbb.ccccc or aaa.bbb.ccccc.ddddd
MSDN:
The value of the ProductVersion property is the version of the product in string format. This property is REQUIRED.
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.
In such cases you official version could be 2010.09.0001, but for Windows Installer you should set for example 210.09.0001 .So you can populate your program till 2055 🙂
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 05, 2010
01:33 PM
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.
Is this actually correct or just an artificial limitation/bug within Installshield ?
From Installshields help:
The Version data type is a text string containing a valid version string. A version string has the format
xxxxx.xxxxx.xxxxx.xxxxx
where x is a digit.
The maximum acceptable version string is 65535.65535.65535.65535.
The following are examples of valid version strings:
• 1
• 1.0
• 1.00
• 10.00
• 1.00.1
• 1.0.1
• 1.00.10
• 1.00.100
• 1.0.1000.0
Is this actually correct or just an artificial limitation/bug within Installshield ?
From Installshields help:
The Version data type is a text string containing a valid version string. A version string has the format
xxxxx.xxxxx.xxxxx.xxxxx
where x is a digit.
The maximum acceptable version string is 65535.65535.65535.65535.
The following are examples of valid version strings:
• 1
• 1.0
• 1.00
• 10.00
• 1.00.1
• 1.0.1
• 1.00.10
• 1.00.100
• 1.0.1000.0
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 06, 2010
10:35 AM
There are two kinds of versions. The one with the 65535 limit for all four fields is a file version. The one with the 255.255.65535 limit is the ProductVersion Property.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 06, 2010
10:56 AM
Michael,
If you wanted to use the full 65535.65535.65535.65535 versioning for the files, that should be okay for the overwriting on minor upgrade, correct? It's just the ProductVersion property that is not able to handle values this high.
Thank you,
-Mike
If you wanted to use the full 65535.65535.65535.65535 versioning for the files, that should be okay for the overwriting on minor upgrade, correct? It's just the ProductVersion property that is not able to handle values this high.
Thank you,
-Mike
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 06, 2010
11:20 AM
Michael*2,
Thanks for the clarification and chapter & verse from Microsoft.
Its a naff restriction but one that we will have to live with I guess.
:rolleyes:
Thanks for the clarification and chapter & verse from Microsoft.
Its a naff restriction but one that we will have to live with I guess.
:rolleyes:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 07, 2010
10:01 AM
@mloebl: Yes, it's definitely safe to use the full 65535 for all four fields in a file version. Generally you'll pull it from the file itself, and I don't think I've ever seen them quite that high. Then again I don't go looking for them. Also of interest is that the always-overwrite option in InstallShield functions by lying about the file's version, so if you do actually have a 65535.x.y.z file version, you may run into trouble mixing it with the always-overwrite option.
@johnoconnor: Yes. The ProductVersion limit can be particularly nasty, as it isn't immediately obvious what the ramifications of breaking the rules are. In practice if you exceed the limits, there are some numeric overflows that can wreak havoc in detecting version numbers for major upgrades. Which is a problem far too many people wouldn't even think to test for, and not all that easy to verify even when you know it's there.
@johnoconnor: Yes. The ProductVersion limit can be particularly nasty, as it isn't immediately obvious what the ramifications of breaking the rules are. In practice if you exceed the limits, there are some numeric overflows that can wreak havoc in detecting version numbers for major upgrades. Which is a problem far too many people wouldn't even think to test for, and not all that easy to verify even when you know it's there.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 07, 2010
03:54 PM
We were always able to put verions of this type 2010.09.0001 in the Application Information page, now we can't. We have way to many applications in this format and need to solve this issue where the last 4 digits determine the upgrade.
Any ideas.
Thank you
Any ideas.
Thank you
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 11, 2010
06:58 PM
Using a product version that exceeds the 255.255.65535 format will cause an ICE03 validation error indicating the product version is invalid. Previous versions of InstallShield did not validate the product version entered. Versions starting with IS 2010 will now check the version entered to ensure it is a valid product version.
You can still use an invalid version by editing the ProductVersion property directly in the Property Manager. Be aware, however, that using a product version that is invalid will eventually cause upgrades to fail version check comparisons made by Windows Installer. (The product version cannot exceed the set values because the product version is stored by Windows Installer as a 4-byte (DWORD) value in the registry. Exceeding any particular element of the version will cause an integer overflow into the next element in the DWORD.)
You can still use an invalid version by editing the ProductVersion property directly in the Property Manager. Be aware, however, that using a product version that is invalid will eventually cause upgrades to fail version check comparisons made by Windows Installer. (The product version cannot exceed the set values because the product version is stored by Windows Installer as a 4-byte (DWORD) value in the registry. Exceeding any particular element of the version will cause an integer overflow into the next element in the DWORD.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 12, 2010
08:30 AM
Thank you very much for you response.
We'll drop the first 2 digits of the first block of numbers in our new builds and still keep the last 2 year-digits in it.
Thank you again.
We'll drop the first 2 digits of the first block of numbers in our new builds and still keep the last 2 year-digits in it.
Thank you again.