files installed under Program Files (x86) are not uninstalled during Remove

[Mescalero]

I have a 64-bit installation (specified as x64 in the template summary) where INSTALLDIR is defined as [ProgramFiles64Folder].

I have a dialog screen where the user can modify INSTALLDIR. If they opt to install to \Program Files (x86)\... on a x64 machine, the installation works fine, but the files fail to uninstall during a Remove. Within the verbose log file of the Remove, I see numerous instances of "Disallowing uninstallation of component: {...} since another client exists".

None of the components is marked as Shared.

This is a 64-bit application, so setting aside for the moment the wisdom of the user even wanting to install under Program Files (x86), why might these files fail to uninstall?

Thanks kindly for any info.

[Vijay__K]

Have you tried to log the uninstall to see what the value for INSTALLDIR is at the time of uninstall?

I suspect its not being stored correctly on install.

[Mescalero]

Hi Vijay, thanks. Yes, and the INSTALLDIR has the correct value, i.e., C:\Program Files (x86)\.

I'm just not sure what the problem is.

[snip_1415]

Please check if the component is marked "Permanent". That can be causing the removal of the files to fail.

Possible for u to share the logfile.

[Mescalero]

Hi,

The components are not marked as permanent. I have attached the log file, thank you.

[snip_1415]

Here i see some problem with the system Dll's. The log file tells that you are installing some system dll's as part of ur package with Feature System_DLLs . Please confirm if its true???

MSI (s) (04:54) [16:14:29:746]: Feature: System_DLLs; Installed: Local; Request: Absent; Action: Absent

If that is true then please confirm if its the system files like MSVCRT.DLL, ntdll.dll which are not getting uninstalled\removed once ur product is removed.

If this all is true than this is expected as these are OS files, there are many OS features using these files and they cannot be removed from ur product since OS features are still using these files. This is the reason u r seeing messages like "Disallowing uninstallation of component: {...} since another client exists".

This is what i got from logfile:

MSI (s) (04:54) [16:14:35:659]: Executing op: FileRemove(,FileName=MSVCRT.DLL,,ComponentId={C929DF8C-EC47-4A56-8E94-FE0B6170DD75})
MSI (s) (04:54) [16:14:35:674]: This following file was not removed, because it is protected by Windows: C:\Windows\system32\MSVCRT.DLL

This clearly tells that Window installer is trying to remove file "MSVCRT.dll" but it cannot remove it because its OS file. There are many entries like this in the log file.

Now i wonder why u want to put system files in ur package as they will surely be present on the system when ur package is installed and u can use them from the local system. Is there a specific need for u to package system files as part of ur product?? I suggest not to package system files as part of ur installation.

Regards
snip

[Mescalero]

Hi Snip,

Yes, I am including some system DLLs with this install. It's for backwards compatibility for some old VB apps that are still included with this (Java) application. That aspect certainly needs a look-see.

However, I disassociated these file components from the parent features, so that they did not install, and still the over-all application does not get removed.

Oddly, if I pick a random component ID such as the following: Disallowing uninstallation of component: {8652057E-EB78-7955-3971-B8E632457783} since another client exists.

and then search for that component GUID earlier in the log to see which file component that is, it does not exist. I have no idea what that component is.

I am using dynamic file linking, which may have something to do with it.

Thanks for your questions and observations.

[Earthshine]

why on earth your you ever let anyone install a 64 bit application under the 32 bit stuff?

this should never be done. for any reason.

[Mescalero]

Well, the user can alter INSTALLDIR during the first-time installation, and though the default setting is the x64 Program Files directory, someone decided to install under PF (x86), leading to this.

But yes, henceforth, installing under (x86) will not be permitted.