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
- :
- Upgrade advice...
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
‎May 13, 2015
08:28 AM
Upgrade advice...
Hi guyz,
We have a product with version 1.0.1, the setup for which is built as an Installshield basic MSI project. The binary files in the release are versioned 1.0.nnnn.1000 where nnnn is the source code repository revision number.
We need to prepare a new release with version 1.0.2. The binaries in the release shall be versioned 1.0.nnnn.2000, where the repository revision value (nnnn) is guarenteed to be greater than that in the 1.0.1 release.
The feature tree, components, custom actions, UI, script etc are going to be the same. In this case, the product GUID need not change, right?. Do we need to author a MINOR UPGRADE in this case?
OR
If we rebuild the install with the updated version number (1.0.2) that includes the new set of binaries, would it automatically do an upgrade when run on top of 1.0.1?
If any unversioned files (like text files) are modified in the new install, would they get updated as well?
Looking forward to your reply,
We have a product with version 1.0.1, the setup for which is built as an Installshield basic MSI project. The binary files in the release are versioned 1.0.nnnn.1000 where nnnn is the source code repository revision number.
We need to prepare a new release with version 1.0.2. The binaries in the release shall be versioned 1.0.nnnn.2000, where the repository revision value (nnnn) is guarenteed to be greater than that in the 1.0.1 release.
The feature tree, components, custom actions, UI, script etc are going to be the same. In this case, the product GUID need not change, right?. Do we need to author a MINOR UPGRADE in this case?
OR
If we rebuild the install with the updated version number (1.0.2) that includes the new set of binaries, would it automatically do an upgrade when run on top of 1.0.1?
If any unversioned files (like text files) are modified in the new install, would they get updated as well?
Looking forward to your reply,
- Tags:
- upgrade
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 13, 2015
09:08 AM
Yes, Author a Minor Upgrade item... and no change in Product GUID and you will notch the product version for Minor upgrade (which you are doing ...1.0.2).
Refer to this for the file overwriting logic which Windows Installer uses.
For version-ed file, it's the highest version which wins and for non-version-ed the modified date comes into play.
Also you may optionally look at this which gives you additional control if at all you need.
Refer to this for the file overwriting logic which Windows Installer uses.
For version-ed file, it's the highest version which wins and for non-version-ed the modified date comes into play.
Also you may optionally look at this which gives you additional control if at all you need.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 14, 2015
08:40 AM
Thanks much for the response.. Was looking at http://helpnet.installshield.com/installshield16helplib/CreatingMinorUpgrades.htm, there it says
Does it mean that if we rebuild the install with the updated version number (1.0.2) that includes the new set of binaries, without authoring a minor upgrade, it would automatically do an upgrade when run on top of 1.0.1?
If you build a release that includes Setup.exe, your latest installation will be minor upgrade enabled. Setup.exe can detect when a previous version of your application exists on a target machine. When Setup.exe detects a previous version, it will run the rest of your installation in minor upgrade mode.
Does it mean that if we rebuild the install with the updated version number (1.0.2) that includes the new set of binaries, without authoring a minor upgrade, it would automatically do an upgrade when run on top of 1.0.1?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 15, 2015
08:45 AM
yup, with every build of InstallShield project by default the Package Code gets changed and that's how setup.exe assumes that the MSI has changed and performs an update.
However, personally I would recommend for the Minor Upgrade item.
I wouldn't know of any consequences if you don't add a Minor Upgrade item.
let's hear if anyone else has any comments here.
However, personally I would recommend for the Minor Upgrade item.
I wouldn't know of any consequences if you don't add a Minor Upgrade item.
let's hear if anyone else has any comments here.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 18, 2015
04:44 AM
Hi,
I created the install with the updated version number. This setup installs the latest files with updted file versions.. However when running the upgrade, I am seeing that some of the files are updated to the latest version, where as the others are untouched.
From the log file
Under InstallValidate action, for all files that are correctly updated during install, the log looks like
where as for those files that are untouched during install, i see
I have checked the component properties and the file properties for both of these, and it looks exactly the same...
Any suggestions to get around this scenario?
I created the install with the updated version number. This setup installs the latest files with updted file versions.. However when running the upgrade, I am seeing that some of the files are updated to the latest version, where as the others are untouched.
From the log file
MSI (c) (4C:1C) [11:47:19:823]: Command Line: REINSTALL=ALL REINSTALLMODE=vomus IS_MINOR_UPGRADE=1 SETUPEXEDIR=C:\Temp\MY PRODUCT SETUPEXENAME=setup.exe CURRENTDIRECTORY=C:\Temp\MY PRODUCT CLIENTUILEVEL=0 CLIENTPROCESSID=3916
Under InstallValidate action, for all files that are correctly updated during install, the log looks like
MSI (s) (38:38) [11:48:13:729]: Component: comp1.dll; Installed: Local; Request: Local; Action: Local
where as for those files that are untouched during install, i see
MSI (s) (38:38) [11:48:13:745]: Component: comp2.dll; Installed: Local; Request: Null; Action: Null
I have checked the component properties and the file properties for both of these, and it looks exactly the same...
Any suggestions to get around this scenario?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 19, 2015
01:08 AM
Check in the log for "Disallowing".
The file which was untouched.... was it a versioned file? and if yes... was it of a higher version when compared to that on the system.
The file which was untouched.... was it a versioned file? and if yes... was it of a higher version when compared to that on the system.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 25, 2015
06:58 AM
Thanks for your support on this. Using the upgrade validate tool I was able to identify the issue. One of the merge modules was referring to the VC9 redistributables. The machine on which i had built the installs did not have that version of vc9 and hence i had remapped to the version that was available on that machine... Since the component ID got changed, it would not allow a minor upgrade on that module and hence the files were not getting overwritten. I copied the VC9 merge modules from the main build VM and rebuilt the installs, with that the issue got resolved and now all files are correctly upgraded...
