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
- :
- Duplicate ARP entries on major upgrade
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
‎Sep 09, 2009
09:20 AM
Duplicate ARP entries on major upgrade
I have several "InstallScript MSI Projects" where major upgrades leave the old entries in the "Add or Remove Programs" control panel utility.
The old product is actually uninstalled. I can observe that files and shortcuts are removed during upgrade process.
This project type adds the following entries to registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield_{...
The problem seems to be that the 'RemoveExistingProducts' action does not remove the 'InstallShield_{...' key in registry. If I manually delete this entry, the product entry is also removed from the "ARP".
If I do a manual uninstall before upgrading, the old product entry is removed as expected.
This seems to have become a problem for us when we upgraded to IS 2010 from 2009. All our products that we have made new installers for, now leave duplicate entries in the ARP, even though nothing should (theoretically) have changed in the installer since IS 2009.
Any ideas? I know this was solved with a hotfix for IS 2009, which leaves me stumped as to why it's happening now in IS 2010.
The old product is actually uninstalled. I can observe that files and shortcuts are removed during upgrade process.
This project type adds the following entries to registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\InstallShield_{...
The problem seems to be that the 'RemoveExistingProducts' action does not remove the 'InstallShield_{...' key in registry. If I manually delete this entry, the product entry is also removed from the "ARP".
If I do a manual uninstall before upgrading, the old product entry is removed as expected.
This seems to have become a problem for us when we upgraded to IS 2010 from 2009. All our products that we have made new installers for, now leave duplicate entries in the ARP, even though nothing should (theoretically) have changed in the installer since IS 2009.
Any ideas? I know this was solved with a hotfix for IS 2009, which leaves me stumped as to why it's happening now in IS 2010.
(4) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 21, 2009
03:42 AM
I have the same problem in IS 2009 in a basic msi project. I have configured my major upgrade as per the IS documentation, but when i install i am left with 2 ARP entries.
Having looked through the msi log i cant seem to determine if my existing installation was found... perhaps my major upgrade configuration is incorrect? if so this could be a dfferent problem.
If anyone could shed any light on configuring a major upgrade that would be great (i have searched the forum for a while now which has got me to this point, so thank for all the help so far).
Having looked through the msi log i cant seem to determine if my existing installation was found... perhaps my major upgrade configuration is incorrect? if so this could be a dfferent problem.
If anyone could shed any light on configuring a major upgrade that would be great (i have searched the forum for a while now which has got me to this point, so thank for all the help so far).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 21, 2009
04:40 AM
It sounds like in both cases that an upgrade didn't occur and you may have just blatted the files over the top of the old version. For there to be two entries installer MUST be presuming that there are two different products on the machine.
You can find out for definite by searching your log for the action FindRelatedProducts. It should give you the product code for the old version it finds.. if it doesn't which i'm presuming it won't then you are installing what looks to installer as a different product altogether.
To do a standard major upgrade, you just need to ensure that the product versions are different, and you need to concentrate on 3 GUIDS in your packages as follows:
Packagecode: These should be different between old and new msi. This basically tells the installer that this is a different msi and that you've not just minor tweaked the same msi as before.
Productcode: The new one needs to be different to the old one because this will tell installer that this is a new product (including major upgrades)
Upgradecode: This is the key one here, these need to match in both installations because this tells installer that they belong to the same product family and will therefore upgrade anything with the same product code
If you do these, you won't need anything in the upgrade table. The upgrade table is used to define products that aren't necessarily the same but are still considered an upgrade in your eyes. For instance you might want to upgrade a single product installer with an installer containing suite of products where one of those is the single product. Or you may have replaced a product with a new branded product and you wanted to start with fresh GUIDS for it.
Some packagers prefer not to use the standard upgrades because the upgrade table provides more flexibility using attributes, version numbers and properties (to identify which upgrades happened). In this case you change all 3 guids and manually enter the upgrade code for the old installer into the upgrade table. This microsoft link explains how to use the upgrade table:
http://msdn.microsoft.com/en-us/library/aa372379(VS.85).aspx
You can find out for definite by searching your log for the action FindRelatedProducts. It should give you the product code for the old version it finds.. if it doesn't which i'm presuming it won't then you are installing what looks to installer as a different product altogether.
To do a standard major upgrade, you just need to ensure that the product versions are different, and you need to concentrate on 3 GUIDS in your packages as follows:
Packagecode: These should be different between old and new msi. This basically tells the installer that this is a different msi and that you've not just minor tweaked the same msi as before.
Productcode: The new one needs to be different to the old one because this will tell installer that this is a new product (including major upgrades)
Upgradecode: This is the key one here, these need to match in both installations because this tells installer that they belong to the same product family and will therefore upgrade anything with the same product code
If you do these, you won't need anything in the upgrade table. The upgrade table is used to define products that aren't necessarily the same but are still considered an upgrade in your eyes. For instance you might want to upgrade a single product installer with an installer containing suite of products where one of those is the single product. Or you may have replaced a product with a new branded product and you wanted to start with fresh GUIDS for it.
Some packagers prefer not to use the standard upgrades because the upgrade table provides more flexibility using attributes, version numbers and properties (to identify which upgrades happened). In this case you change all 3 guids and manually enter the upgrade code for the old installer into the upgrade table. This microsoft link explains how to use the upgrade table:
http://msdn.microsoft.com/en-us/library/aa372379(VS.85).aspx
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Sep 29, 2009
07:45 AM
Like I said, this seems not to have happened before.
All the GUIDs are proper. I got confirmation from tech support that this is still an issue, and the projects from IS 2009 should be rebuilt with the hotfix, then imported into 2010.
That's not much of an option, since the projects from 2009 are of course in the hands of end users ages ago.
So, it seems we will have to use a custom action to clear out old GUIDs from the registry during install.
By the way, we use the Upgradetable as well. What seems to happen is that the issetup.dll that shipped with IS 2009 doesn't uninstall the previous software completely, leaving the registry entries that ARP picks up on.
All the GUIDs are proper. I got confirmation from tech support that this is still an issue, and the projects from IS 2009 should be rebuilt with the hotfix, then imported into 2010.
That's not much of an option, since the projects from 2009 are of course in the hands of end users ages ago.
So, it seems we will have to use a custom action to clear out old GUIDs from the registry during install.
By the way, we use the Upgradetable as well. What seems to happen is that the issetup.dll that shipped with IS 2009 doesn't uninstall the previous software completely, leaving the registry entries that ARP picks up on.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Nov 06, 2012
11:36 PM
You need to clean the registry files that will remove the older files and will keep the upgraded files.
