Video Screencast Help

Wise install shared dll count question.

Created: 13 Feb 2014 | 4 comments

I'm trying to tweak an install we have in Wise on my XP machine before they take it away from me.  I'm not an installer and was handed this job as a result of downsizing years ago.  My question is about shared dll counts I think.  We have a merge module that installs 12 files and of those 12, one of those is an ini file created in the MSM that puts on the 12 files.  We have two applicatiions that share the 12 files this merge module puts on.  When I install, I've looked in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls and see only 6 of the files.  My question is why doesn't it delete 6 of my files when I unisntall one of my applications.  I know the other remaining app still needs them, but how are they hanging around if they aren't in the shared dll area in the registry?  So basically after the uninstall of one of the apps all 12 files remain and I'd think there should be 6.

Thanks in advance.


Operating Systems:

Comments 4 CommentsJump to latest comment

SK's picture

Can you provide the project file tgat you created the msi from so that we may look at it.

Connect Etiquette: "Mark as Solution" those posts which resolve your problem, and give a thumbs up to useful comments, articles and downloads.

EdT's picture

There is a simple answer to this.  MSI installs reference count by component GUID. Legacy installs reference count by incrementing/decrementing the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls 

The purpose of a merge module is to ensure that each time the MM is installed, the same guids are used for reference counting. However, with a tool like WPS and conflict manager, you can quickly find DLLs in your install which are identical but in components with different GUIDs and thereby manually tweak the new install so that identical files maintain identical guids without having to create and manage merge modules.

The MSI reference counting occurs here for "admin" components in the registry:


For user components, the user SID replaces the admin SID in the path above.

GUIDS are present in compressed form in the registry.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

pbishop's picture

Ed...I think I'm confused still.  I looked in that registry key and I only see the same 6 files that are in SharedDlls key.  So let me ask it this way.  So besides tweaking some on my XP/Wise machine, we are also in the process of rewriting all of our installs.  As of now we are trying out this InstallMate software as our installs really aren't that complicated.  How when you make a new install can you detect these files that aren't in the SharedDll's section?  The new install program we are trying to use uninstalls 6 of the files and leaves the 6 that are in the SharedDll's section.  So similar to what I'm trying to tweak in a wise install I'm also going to have to know how to do going forward.  Do you know how I can look for the other 6 files and decide whether or not they have any dependencies?



EdT's picture

Microsoft make this a little easier for you by specifically stating that DLL files and other runtime content that is installed into the System32 folder should never be removed. That is their "recommendation".

The SharedDlls registry location was provided by Microsoft prior to the release of the MSI technology to help avoid "DLL Hell" as prior to this there was no mechanism whatsoever for avoiding the removal of a shared DLL when an app was uninstalled that used the shared DLL.

With MSI technology, components replaced files as the unit of reference counting, and therefore it was really up to the packager to ensure that files being installed which might be shared files would therefore be given an identical component guid or placed in a merge module to ensure reliable reference counting.

Realistically though, there is still no 100% effective mechanism for reference counting that is installer neutral.  Ideally, vendors should place their own DLL files in the program folder and then there is no sharing involved and uninstall is straightforward. If DLL files are placed in the System32 or Windows folders then the components should be set as permanent and never uninstalled.

If the requirement is for all unnecessary files to be uninstalled, then you are going to have to manage this using your packaging tool so that identical files installing to the same folder are correctly reference counted regardless of which method of ref counting is used.

Does this give you enough to work with?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.