12 replies to this topic

[overlordchin]

IS2009 installer leaves behind shared components that are not permanent upon uninstall when no other programs that use those components are present. Any thoughts as to why this would occur or if there is some other place i need to make changes to fix the issue? They used to be permanent and were changed so they would not be left behind only they still are.

Edited by overlordchin, 31 January 2011 - 15:24.

[Stefan Krueger]

Are you testing on a clean machine (fresh OS image) or on one that previously had the version with permanent components installed?

[overlordchin]

on a fresh os that didnt previously have the components installed. My first thought was there was some sort of GUID clobbering going on. That does not seem to be the case.

[Stefan Krueger]

A few things to check:

Open the msi in direct edit mode or in InstaEd or Orca to double check that the permanent flag is really gone.

Clear the "shared" flag. Does the component properly uninstall then (on a clean machine)?

Check the value to the SharedDll count in registry for the files in question. Check them before install, after instalm and after uninstall.

Generate a log of the uninstall to see why Widows Installer doesn't remove the files.

Where do you install those files? Somewhere under Program Files or maybe in Windows or System32 folder?

Did you run validation for your build in InstallShield? It can detect a number of potential problems.

[overlordchin]

I will look into this:

[overlordchin]

In the validate section only the upgrade validation is not grayed out. If I run that it dumps an empty log file (0KB) down. Are these features I do not have installed somehow or what?

[overlordchin]

I looked at the values of the registry key. there was a key for the component but there was no value assigned to it. I removed the software and then manually removed the key thinking it was a left over from the installer. So I assumed the key would come back when I re-installed. It does not (which might be why it is not getting cleaned up) It is not actually marking it as shared somehow?

[Stefan Krueger]

The registry key is only created if you set the "shared" flag to yes. It is used for compatibility with legacy setups. Windows Installer has its own method of reference counting.

[overlordchin]

the shared flag is in fact set to yes on the component page. Is there some other place I need to designate it as shared? Also you suggested earlier that I need to validate the project to show if it is really the way i think it is. Can you elaborate on this process?

[overlordchin]

[Stefan Krueger]

If this file will only be installed by Windows Installer (and not some legacy installer in some other setup), then you don't need to set the shared flag. Windows Installer keeps record of which products are using a component, and will only remove it when the last product is uninstalled. So this is more detailed than the simply counter that legacy setups use in registry. If oyu set the shared flag to yes, Windows Installer will - in addition to its own method - also update the registry count for backward comatibility.

To validate an update, you must first specify the older setup in the Updates view. Then you should be able to perform update validation.

[overlordchin]

Stefan, thanks for all your input. Just a few more issues here. This particular component can be installed by any number of products we have. It is common to all of our installers and in each of them it is set to shared with the same GUID. all of the other products appear to do reference counting correctly and do not leave this file behind if nothing else is present on the system that currently uses the shared component. If you use the installer I have been asking about however, the component is left behind on an uninstall. So validating against an older version of this installer does not really help me in this case.

I have tried un-setting the shared flag. Saving and starting a build. Then going back and resetting it back to shared and rebuilding again. The problem still persists. I do not understand why only this particular installer seems to have a problem with the shared component (there are actually about 5 shared components in this installer that have this problem). While the others seem to work as expected with the same settings.

[Stefan Krueger]

I also don't know why it works in the other installers but not in this. Thjere must be something different.