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
- :
- Re: Installshield 2011 leaves assemblies behind on uninstall
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
Nov 08, 2011
05:28 AM
Installshield 2011 leaves assemblies behind on uninstall
Hi,
We are using Installshield 2011/VS2010. We have a basic msi package with individual features for various plugin features. Some of the features have components that have same assembly (key file) as in the components of other features.
Ex:
Common Feature
-- Sub Feature 1
SubFeature1_Assembly_Foo
SubFeature1_Assembly_2
-- Sub Feature 2
SubFeature2_Assembly_Foo
SubFeature2_Assembly_3
-- Sub Feature 3
SubFeature3_Assembly_Foo
SubFeature3_Assembly_4
If you see above the Assembly Foo is being used in three components. All the features install in the same installation directory. All the three components are marked as "Shared" and I can see the reference count in the registry path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs as 3.
Now on an uninstall as per installshield design the reference count should decrement during unistall of each feature and at the end should remove the assembly. But that is not the case. Instead all the assemblies that are shared between feature are left behind on the disk and the registry is cleared. it almost seems like installshield does not decrement the reference count at all.
So, how do I get these shared assemblies removed from the disk (without doing any funky custom actions and all).
Thanks
We are using Installshield 2011/VS2010. We have a basic msi package with individual features for various plugin features. Some of the features have components that have same assembly (key file) as in the components of other features.
Ex:
Common Feature
-- Sub Feature 1
SubFeature1_Assembly_Foo
SubFeature1_Assembly_2
-- Sub Feature 2
SubFeature2_Assembly_Foo
SubFeature2_Assembly_3
-- Sub Feature 3
SubFeature3_Assembly_Foo
SubFeature3_Assembly_4
If you see above the Assembly Foo is being used in three components. All the features install in the same installation directory. All the three components are marked as "Shared" and I can see the reference count in the registry path HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs as 3.
Now on an uninstall as per installshield design the reference count should decrement during unistall of each feature and at the end should remove the assembly. But that is not the case. Instead all the assemblies that are shared between feature are left behind on the disk and the registry is cleared. it almost seems like installshield does not decrement the reference count at all.
So, how do I get these shared assemblies removed from the disk (without doing any funky custom actions and all).
Thanks
(1) Reply
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
Nov 08, 2011
03:59 PM
If this file is being included in multiple components that are all installing to the same folder, component authoring rules have been broken and is quite likely the cause of the behavior you are seeing.
Please see the following articles for more information (assuming this is a Basic MSI or InstallScript MSI project):
ICE30
Organizing Applications into Components
Defining Installer Components
What happens if the component rules are broken?
Removing Stranded Files
Including a file in multiple components that all install to the same path results in Windows Installer considering the file as share by multiple products. However, since only one product includes the components, the reference counting for the file is broken and the file will never be removed. Shared files generally should be included in one component, possibly including that component in one common feature if possible to simplify the feature/component tree. If the file needs to be included in multiple components, some mechanism must be in place (component conditions, mutually exclusive features, etc.) to ensure that only one of the components is ever installed from the product on a given machine. If more than one of the components is ever installed, the file will never be removed.
Please see the following articles for more information (assuming this is a Basic MSI or InstallScript MSI project):
ICE30
Organizing Applications into Components
Defining Installer Components
What happens if the component rules are broken?
Removing Stranded Files
Including a file in multiple components that all install to the same path results in Windows Installer considering the file as share by multiple products. However, since only one product includes the components, the reference counting for the file is broken and the file will never be removed. Shared files generally should be included in one component, possibly including that component in one common feature if possible to simplify the feature/component tree. If the file needs to be included in multiple components, some mechanism must be in place (component conditions, mutually exclusive features, etc.) to ensure that only one of the components is ever installed from the product on a given machine. If more than one of the components is ever installed, the file will never be removed.