5 replies to this topic

[wimcolgate]

I've done a bunch of web searches and found tantalizingly close suggestions on how to fix the "multiple entries in install/uninstall" problem after upgrade.

 

To summarize what I have double checked:

 

1) Product codes are different.

2) Upgrade codes are the same.

3) It is a MAJOR upgrade

 

From the MSI log:

 

 

InstallShield 13:24:11:         [redacted] {6DD9B95C-E38F-471F-AAE5-362918472D22}  1033    6.0.0.166065     ***Related***

MSI © (34!54) [13:24:11:927]: PROPERTY CHANGE: Adding IS_MAJOR_UPGRADE property. Its value is 'Yes'.

InstallShield 13:24:11: ALLUSERS of related product {6DD9B95C-E38F-471F-AAE5-362918472D22} is = 1

 

The upgrade does shutdown the running application and installs the new one, starts, etc.

 

As far as everyone is concerned the upgrade was successful. The only baggage is that there are two entries in the add remove (install/uninstall) system applet. Since the upgrade is in-place, removing either one removes the installed software; and trying to remove the second fails with an error (obviously it has been removed) -- and the second entry is in the applet is removed.

 

I'm willing to take on an experiment with anyone's suggestion on how to make the upgrade remove the older entry.

 

If any one needs any more information I'll be happy to supply it.

 

Regards,

 

Wim

 

 

 

[Stefan Krueger]

The log entry you posted is InstallShield's custom action to detect the ALLUSERS setting of the previous version. Please look for MSI's entries for FindRelatedProducts and RemoveExistingProducts.

In your Upgrade settings make sure that the "Remove" setting is empty.

Did you inspect the Uninstall entry in registry? Is is a Windows Installer entry or maybe customized in some way? (Registry table for instance)

 

And then there's the possibility that it's not a problem in your msi but a refresh issue in control panel. Did you reboot the machine and the second entry is still there?

[wimcolgate]

Here is what I can find in my MSI log file:

 

MSI © (24:80) [11:49:24:278]: Doing action: FindRelatedProducts
Action 11:49:24: FindRelatedProducts. Searching for related applications
Action start 11:49:24: FindRelatedProducts.
Action ended 11:49:24: FindRelatedProducts. Return value 1.


...

Action 11:49:35: FindRelatedProducts. Searching for related applications
Action start 11:49:35: FindRelatedProducts.
MSI (s) (68:1C) [11:49:35:916]: Skipping FindRelatedProducts action: already done on client side

...

MSI (s) (68:1C) [11:49:44:193]: Doing action: RemoveExistingProducts
Action 11:49:44: RemoveExistingProducts. Removing applications
Action start 11:49:44: RemoveExistingProducts.
Action ended 11:49:44: RemoveExistingProducts. Return value 1.
 

 

As for:

 

"In your Upgrade settings make sure that the "Remove" setting is empty."

 

Are you referring to InstallShields Upgrades --> Upgrade Windows Installer Serup --> [MajorUpgrade | ISPreventDowngrade] advanced settings? There is a field in both that is "Only remove specified features" -- both are blank.

 

 

[wimcolgate]

One thing I *forgot* to add -- which is probably quite important: The upgrade is within the same version number. For example: 6.0.0.1234 to 6.0.0.1235 -- the true x.y.z version is the same, only the "not really accounted for" string at the tail end of the version changes. And the ISPreventDowngrade allows 6.0.0 to install ontop of 6.0.0.

[deramor]

If I remember correctly, the last number is ignored by Windows Installer.  Is there some reason you do not bump the 3rd number?  The 3rd number is usually reserved for repeated builds of a product and is expected to increment many times.  The 4th number is usually for updates or patches and (I believe) is ignored.

 

My upgrade/removal method is the same as what you are trying to do and it works for me.  I will try to explain what I did.

 

1. Set and never change your upgrade code.

2. Change your package and product code with each build.

3. Change your product version with each build.  I change the "build" number xxx.yyy.zzzzz  (zzzzz in this example)

4. I have 2 major upgrades defined.  A prevent downgrade and an upgrade item I created.

 

The upgrade item I created has the following settings:

- The upgrade code can be either radio button so long as the code in this box matches the one on your project.

- The version to upgrade is any earlier version

 

After doing this, I do not get duplicate entries in add/remove (programs and features).

Hope this helps.

[Stefan Krueger]

Here is what I can find in my MSI log file:

 

MSI © (24:80) [11:49:24:278]: Doing action: FindRelatedProducts
Action 11:49:24: FindRelatedProducts. Searching for related applications
Action start 11:49:24: FindRelatedProducts.
Action ended 11:49:24: FindRelatedProducts. Return value 1.
...

Any products it found would be listed here, so this means that it didn't find a related product to remove.

 

One thing I *forgot* to add -- which is probably quite important: The upgrade is within the same version number. For example: 6.0.0.1234 to 6.0.0.1235 -- the true x.y.z version is the same, only the "not really accounted for" string at the tail end of the version changes.

That's the problem. For a Major Upgrade you need to increment the ProductVersion in one of the first three fields.

 

If I remember correctly, the last number is ignored by Windows Installer. 

That's correct, and this is most likely the cuase of the problem.