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
- :
- "Completely uninstall old setup before installing new setup", incorrect behaviour
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
Mar 08, 2016
08:51 AM
"Completely uninstall old setup before installing new setup", incorrect behaviour
I'm not sure whether this should be logged as a bug or not, but I've noticed issues with upgrading when file versions are the same, lower or non existant.
Due to potential issues with file versions I set the following Major Upgrade radio button in my Upgrade tab:
"Completely uninstall old setup before installing new setup"
This is stated to be the most reliable setting, but least efficient. As files that haven't changed will be removed then reinstalled. That is exactly what I want, but I don't get that.
Assume I have a file versioned at 3.0.2. installed and my upgrade attempts to replace it with version 3.0.1. The MSI engine removes the original file as per "Completely uninstall old setup before installing new setup", but then notes that the new file is a lower version and decides not to replace it, with the result that no file is left on the system. Same happens with unversioned files with older dates and even same version files. In my view it should either blindly remove everything (like it does) but then blindly put everything back. Or, decide before removing a particular file that it isn't going to replace it due to it being an older version and leave the original file in place.
Now some will say, why would I want to upgrade with an older file? I wouldn't, but if this cock up happened, an older file is better than no file and this scenario isn't as unlikely as it sounds (see example below). If the setting "Completely uninstall old setup before installing new setup" is in play, it shouldn't be comparing version numbers and file dates to decide whether or not to actually put them back.
It seems the only sure fire workaround is to additionally set every individual file property to "Always Overwrite", but that is a huge task when dozens if not hundreds of files exist.
_______________________
Example:
Assume you have two released versions of a product 1.0.0 and 2.0.0, the second is a paid upgrade and some customers will not upgrade, but still expect bug fixes on their 1.0.0 version. An urgent bug fix is required and an intermediate 1.0.1 is released to upgrade 1.0.0 The bug is not present in 2.0.0 and no upgrade is needed. A merge module which uses a different set of version numbers is rebuilt for the 1.0.1 release with the result that:
Product 1.0.0 uses merge module files versioned at 12.0.162
Product 1.0.1 uses merge module files versioned at 12.0.208
Product 2.0.0 uses merge module files versioned at 12.0.197
The files in the merge module might not have actually changed internally, but they were rebuilt as part of the build process and Product 1.0.1 files get a later build number and with unversioned files a later build date. Then upon upgrading 1.0.1 to 2.0.0, everything goes to pieces because a load of files are removed but not replaced.
Due to potential issues with file versions I set the following Major Upgrade radio button in my Upgrade tab:
"Completely uninstall old setup before installing new setup"
This is stated to be the most reliable setting, but least efficient. As files that haven't changed will be removed then reinstalled. That is exactly what I want, but I don't get that.
Assume I have a file versioned at 3.0.2. installed and my upgrade attempts to replace it with version 3.0.1. The MSI engine removes the original file as per "Completely uninstall old setup before installing new setup", but then notes that the new file is a lower version and decides not to replace it, with the result that no file is left on the system. Same happens with unversioned files with older dates and even same version files. In my view it should either blindly remove everything (like it does) but then blindly put everything back. Or, decide before removing a particular file that it isn't going to replace it due to it being an older version and leave the original file in place.
Now some will say, why would I want to upgrade with an older file? I wouldn't, but if this cock up happened, an older file is better than no file and this scenario isn't as unlikely as it sounds (see example below). If the setting "Completely uninstall old setup before installing new setup" is in play, it shouldn't be comparing version numbers and file dates to decide whether or not to actually put them back.
It seems the only sure fire workaround is to additionally set every individual file property to "Always Overwrite", but that is a huge task when dozens if not hundreds of files exist.
_______________________
Example:
Assume you have two released versions of a product 1.0.0 and 2.0.0, the second is a paid upgrade and some customers will not upgrade, but still expect bug fixes on their 1.0.0 version. An urgent bug fix is required and an intermediate 1.0.1 is released to upgrade 1.0.0 The bug is not present in 2.0.0 and no upgrade is needed. A merge module which uses a different set of version numbers is rebuilt for the 1.0.1 release with the result that:
Product 1.0.0 uses merge module files versioned at 12.0.162
Product 1.0.1 uses merge module files versioned at 12.0.208
Product 2.0.0 uses merge module files versioned at 12.0.197
The files in the merge module might not have actually changed internally, but they were rebuilt as part of the build process and Product 1.0.1 files get a later build number and with unversioned files a later build date. Then upon upgrading 1.0.1 to 2.0.0, everything goes to pieces because a load of files are removed but not replaced.
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Mar 24, 2016
06:34 AM
We've come across this problem on numerous occasions in the past, I finally found what I believe to be the answer here:
http://www.laurierhodes.info/?q=node/46
In a nutshell, the problem is that Windows Installer evaluates the components *before* the previous version is uninstalled, meaning that components may not be marked for inclusion because they are older/have not changed. The uninstall then removes these components, and when the install stage goes through those components are not marked to be installed. According to that article, Windows Installer expects that the RemoveExistingProducts custom action is performed at the end of the installation as a kind of "cleanup" operation, not at the start as InstallShield traditionally places it. If it is placed at the beginning then the ref counting mechanism does not work, thus components can go missing. We are in the process of moving RemoveExistingProducts to the end of the Installation/Execute sequence for all our products as this appears to be much more reliable.
Hope this helps.
http://www.laurierhodes.info/?q=node/46
In a nutshell, the problem is that Windows Installer evaluates the components *before* the previous version is uninstalled, meaning that components may not be marked for inclusion because they are older/have not changed. The uninstall then removes these components, and when the install stage goes through those components are not marked to be installed. According to that article, Windows Installer expects that the RemoveExistingProducts custom action is performed at the end of the installation as a kind of "cleanup" operation, not at the start as InstallShield traditionally places it. If it is placed at the beginning then the ref counting mechanism does not work, thus components can go missing. We are in the process of moving RemoveExistingProducts to the end of the Installation/Execute sequence for all our products as this appears to be much more reliable.
Hope this helps.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)