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
- :
- Major Upgrade Issue/Bug/Procedural Problem
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
‎Feb 09, 2011
09:36 AM
Major Upgrade Issue/Bug/Procedural Problem
Hi all,
This post is kind of an offshoot to..
http://community.flexerasoftware.com/showthread.php?t=196555
Something is wrong with how the Major Upgrade process is acting. I don't know if its a bug, a missing setting in the Upgrades view in IS or what.
Here's the Scenario....
This takes into account that we have a bad versioned file in our latest release (version < what was deployed with earlier release(s)). This condition is good for this testing.
I install the latest release with no upgrade of previous versions and the file is installed and its shortcut created, which is to be expected.
I install a previous version then uninstall it MANUALLY and install the latest version. Again, the file is placed and the shortcut created, also expected.
Now, I install previous version and run install for the latest, which has RemoveExistingProducts sequenced after InstallValidate. This will remove old prodcucts first. This does appear to happen, but when the latest gets installed, the badly versioned .exe in question does not get installed, hence no shortcut. NOT expected.
What is going on here? I would expect the Major Upgrade to act in the same fashion as the manual removal of the previous version scenario. There should be nothing governing what is placed with the latest release once the old release removed. Why does this not seem to be the case? Is there a setting in InstallShield I'm missing? Is this a bug? Is there some facet of Major Upgrades that I am unaware of?
This concerns me greatly because we rely on Major Upgrades to update our Client workstation application.
PLEASE HELP. Should I contact InstallShield support on this one?
Thanks in Advance!!
This post is kind of an offshoot to..
http://community.flexerasoftware.com/showthread.php?t=196555
Something is wrong with how the Major Upgrade process is acting. I don't know if its a bug, a missing setting in the Upgrades view in IS or what.
Here's the Scenario....
This takes into account that we have a bad versioned file in our latest release (version < what was deployed with earlier release(s)). This condition is good for this testing.
I install the latest release with no upgrade of previous versions and the file is installed and its shortcut created, which is to be expected.
I install a previous version then uninstall it MANUALLY and install the latest version. Again, the file is placed and the shortcut created, also expected.
Now, I install previous version and run install for the latest, which has RemoveExistingProducts sequenced after InstallValidate. This will remove old prodcucts first. This does appear to happen, but when the latest gets installed, the badly versioned .exe in question does not get installed, hence no shortcut. NOT expected.
What is going on here? I would expect the Major Upgrade to act in the same fashion as the manual removal of the previous version scenario. There should be nothing governing what is placed with the latest release once the old release removed. Why does this not seem to be the case? Is there a setting in InstallShield I'm missing? Is this a bug? Is there some facet of Major Upgrades that I am unaware of?
This concerns me greatly because we rely on Major Upgrades to update our Client workstation application.
PLEASE HELP. Should I contact InstallShield support on this one?
Thanks in Advance!!
(7) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 10, 2011
08:14 AM
I suspect what you're running into is the following:
I have found that even though you have scheduled the RemoveExistingProducts version early, the costing that happens marks the component with your badly-versioned file as not needed due to having a higher-versioned file on the system.
Then the uninstall is run and the older dll is removed.
Then the install runs, but that component is skipped. You can verify that this is happening by logging the install and checking the states for the component in question.
I believe you can overcome this, since you are completely uninstalling the older version first, by changing the component code on the file in question. then the install will see it as new and mark it for installation, the uninstall will remove the old file, and the install will install the new file as part of a new component. (If the RemoveExistingProducts action was scheduled after the new version is installed, this wouldn't work.)
I have found that even though you have scheduled the RemoveExistingProducts version early, the costing that happens marks the component with your badly-versioned file as not needed due to having a higher-versioned file on the system.
Then the uninstall is run and the older dll is removed.
Then the install runs, but that component is skipped. You can verify that this is happening by logging the install and checking the states for the component in question.
I believe you can overcome this, since you are completely uninstalling the older version first, by changing the component code on the file in question. then the install will see it as new and mark it for installation, the uninstall will remove the old file, and the install will install the new file as part of a new component. (If the RemoveExistingProducts action was scheduled after the new version is installed, this wouldn't work.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 10, 2011
08:21 AM
The GUIDs are already different since we've rebuilt the Wise installs now with InstallShield. This still has the same effect.
I still this situation as a Windows Installer shortcoming. A Major Upgrade should as as if the previous version of the product was manually uninstalled via Add/Remove Programs, re-execution of the original .msi, etc. In these instances I don't have the problem. This is how I thought MUs would work, but I guess not. Costing with reference to the previous version should not be taken into account.
Thanks for the replies by the way!!!
I still this situation as a Windows Installer shortcoming. A Major Upgrade should as as if the previous version of the product was manually uninstalled via Add/Remove Programs, re-execution of the original .msi, etc. In these instances I don't have the problem. This is how I thought MUs would work, but I guess not. Costing with reference to the previous version should not be taken into account.
Thanks for the replies by the way!!!
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 17, 2011
04:16 PM
I would try 2 things.
1) Try setting the "Migrate Feature State" in the upgrade table to No.
or
2)If the component is shared or has the same guid there may be something funky happening in the registry. Perhaps the SharedDLL count in the registry is not being properly incremented or decremented. Try making the component not shared.
Try them seperately and together. I have had problems that were caused by both.
1) Try setting the "Migrate Feature State" in the upgrade table to No.
or
2)If the component is shared or has the same guid there may be something funky happening in the registry. Perhaps the SharedDLL count in the registry is not being properly incremented or decremented. Try making the component not shared.
Try them seperately and together. I have had problems that were caused by both.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 17, 2011
04:29 PM
I thought there was a setting somewhere in the Releases view for Migrate Feature state. I believe it is already set to know, but I can't find the setting to double check.
I can parse the Attributes I guess.
I can parse the Attributes I guess.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 18, 2011
10:44 AM
Ah yes, thanks for the reminder.
Migrate Feature States already = No and the components involved were not shared nor did they share the same GUIDs.
Migrate Feature States already = No and the components involved were not shared nor did they share the same GUIDs.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 21, 2011
02:32 AM
Does that help?
http://community.installshield.com/showthread.php?t=142624
This is another thread about a similar issue.
The work around might well work, but this is not what M$ recommends. You will see a few extra warnings or errors in the validation if you use this workaround, but at least it should work.
http://community.installshield.com/showthread.php?t=142624
This is another thread about a similar issue.
The work around might well work, but this is not what M$ recommends. You will see a few extra warnings or errors in the validation if you use this workaround, but at least it should work.
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)