Page 1 of 2

ARP entry not removed during Previous Version Uninstallation

Posted: Wed Jun 27, 2007 9:03 am
by jweksej
The entry remains with the icon reverted to default. The acces to remove application manually gives the answer so "the application may have been already uninstalled. Would you like to remove it from ARP list?"

My installer extends title displayed in ARP with full app version (with build#) so the same program version installers can have different title displayed.
Can it be a reason?
Could someone propose workaround for it but without changing ARP entry title?

Re: ARP entry not removed during Previous Version Uninstalla

Posted: Sat Aug 04, 2007 2:01 pm
by alma88
I have the same problem. When installing a new version of ProductX the previous version is automatically removed, as it should. However, the entry for the previous version remains in the ARP, with the icon reverted to default. When this old entry's "Remove" button is pressed, the following dialog appears:

An error occured while trying to remove ProductX. It may have been already uninstalled.

Would you like to remove ProductX from the Add or Remove programs list?


The title of the dialog box just displays "Uninstaller Error", without additional info.

This error is fully reproducible with all our installations. I am using the currently available IA 7 (I think it's 7.01, but 7.0 is displayed in the Version dialog).

BTW, I had this problem even with IA itself when I upgraded to 7.

Can someone at IA help please?

Posted: Mon Aug 06, 2007 6:10 am
by jweksej
It looks I found the reason - in my case I always extended product name with version number so each product version has the same product GUID but different product name displayed. The registry key where ARP data are stored is:
[HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Unintall\\<ProductName>]
My workaround is to keep in registry last installed product name and after previous version uninstallation I create appriopriate reg file and using regedit I remove this key from registry.

Posted: Mon Aug 06, 2007 8:04 am
by alma88
jweksej wrote:...so each product version has the same product GUID but different product name...
Same here. Now that the cause has been pinpointed, can we have an urgent fix please?

Posted: Mon Aug 06, 2007 9:14 am
by jweksej
Sure. I do it this way:
1. Read Registry Key HKLM\\SOFTWARE\\$COMPANY$\\$PRODUCT_NAME$\\Version into RET_VAL
2. Install/Remove MSI Package $PRODUCTCODE$[REMOVE=ALL] (get result into variable REMOVEOLD)
if Variable REMOVEOLD Equals ERROR
MessageBox: $PRODUCT_NAME$ Setup, Unable to uninstall old version of $PRODUCT_NAME$. Please uninstall it yourself using Control Panel Add-Remove Programs before attempting to install this product.$NEWLINE$$NEWLINE$$ERROROLD$
Terminate Installation
else
Run Program $SUPPORTDIR$\\clearARP.bat $COMPANY$ $PRODUCT_NAME$ $RET_VAL$ >$SUPPORTDIR$\\clearARP.reg (WAIT)
Run Program regedit.exe /s $SUPPORTDIR$\\clearARP.reg (WAIT)
Run Program del /F /Q $SUPPORTDIR$\\clearARP.reg (WAIT)
end

where clearARP.bat content is as follow:
echo Windows Registry Editor Version 5.00
echo [-HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\%1 %2 %3]

The parameters %1%2%3 are used to create previous version product name.

And don't forget to add:
Write Registry Key HKLM\\SOFTWARE\\$COMPANY$\\$PRODUCT_NAME$\\Version, $VER_FULL$
where the full version of current product is stored.

The TITLE displayed in ARP applet is:
Set Variable TITLE to $COMPANY$ $PRODUCT_NAME$ $VER_FULL$

I hope it will help you.
regards
Jarek

Posted: Mon Aug 06, 2007 10:21 am
by alma88
Thanks, that's neat!

I was rather looking for a fix from IA though... IMO this is a basic bug that needs to be properly addressed asap.

Posted: Mon Aug 06, 2007 1:16 pm
by jimo
Jarek,

That seems like a lot work.

Try this.

Read in the value of DisplayName from
HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\[Your App Prodcut Code} into PROD_NAME

Then:
Delete Registry HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\$PROD_NAME$

Of course do this right after uninstall and before install.

Posted: Tue Aug 07, 2007 3:28 am
by jweksej
Not exactly. In my case DisplayName contains only product name, DisplayVersion contains the version and Publisher has the full company name, not the short one used in ARP. The string you named here as PROD_NAME HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\[PROD_NAME]
is in fact TITLE in IA meaning and in my case it is combined as:
"[ShortCompanyName] [PROD_NAME] [FULL_VERSION]"

The use of regedit instead of DeleteRegistry was intentional, because will be executed always and just after uninstall. DeleteRegistry requires later 'ApplyInstall' what is not guaranteed - user can press 'Cancel'. Tracing this case will be more complicated and dispersed in the script.

Posted: Tue Aug 07, 2007 7:55 am
by alma88
What about a proper fix to this bug instead of discussing workarounds? It's not some exotic feature, this is basic stuff. Please, can we have a formal IA response on how soon a fix will be available? It make us look stupid to our customers if our installations fail in such a manner.

Posted: Tue Aug 07, 2007 1:21 pm
by jweksej
But this is not IA bug!! IA assumes so the product with the same GUID has always the same name. I've broken this rule and now I'm looking for the workaround to keep all consistent. We can talk about new IA feature if it will be important for more customers. Up to now, the workaround is ok for me.

Posted: Tue Aug 07, 2007 1:53 pm
by Gizm0
Exactly. It's not a IA bug.

Posted: Tue Oct 23, 2007 9:47 am
by alma88
I am returning to this old topic because it is still causing problems. Let me start from scratch, maybe I got something wrong in the first place.

We have two products, A and B. We don't want both of them to be present simultaneously on the same machine -- either only A or only B should be installed. The products have different names and different versions.

Q: what should I do so that when IA installs A it will check if B is already installed, and if it is then it will uninstall B before installing A (and of course the same when B is being installed and A is already there)?

Posted: Tue Oct 23, 2007 11:03 am
by Chris Miller
Can you use the technique that was suggest by jimo:
Read in the value of DisplayName from
HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\[Your App Prodcut Code} into PROD_NAME

Then:
Delete Registry HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\$PROD_NAME$

Of course do this right after uninstall and before install.
A would look for B's Product Code and vice versa. I wouldn't call this an IA bug, but a limitation with a fairly straight forward work around. It's pretty common for applications to install with part of the version number in the product name but the work around is easy to implement.

Posted: Thu Mar 12, 2009 8:33 pm
jweksej wrote:But this is not IA bug!! IA assumes so the product with the same GUID has always the same name. I've broken this rule and now I'm looking for the workaround to keep all consistent. We can talk about new IA feature if it will be important for more customers. Up to now, the workaround is ok for me.
I guess I would view this as a bug. The GUID concept was created to be the "unique" name of the product. If a developer adds a version number to the name, or just changes the after time but it is still the "same product" and GUID (which I assume would be rather frequently), I cannot think of any reason why the uninstall should leave the old name in the ARP. Why even use a GUID if it is just gonna look at the name???

I know we can work around this (with the magic of MSIcode :D ), but I cannot imagine why IA would not just uninstall the previous version completely.

Doesn't every IA install script ever created need to add this "fix" to ensure junk is not left in the ARP entries?

Re: ARP entry not removed during Previous Version Uninstalla

Posted: Thu Mar 12, 2009 8:38 pm
alma88 wrote: BTW, I had this problem even with IA itself when I upgraded to 7.
LOL! I think this statement solidifies the thought that the installer should handle this scenario. If the install program's installer itself also forgot to add the "fix" to it's install script, perhaps IA should reconsider that this should be built into IA rather than hand tooled into each script?