Why Are New Components Shared by Default?

Yes

Summary

This article provides information on what the 'Shared' setting does for components and why new components are set to 'Shared' by default

Synopsis

What effect does the 'Shared' setting have on a component?

Windows keeps a reference count for files that are installed on the system. This reference count is the number of products on the system that use the file. When a file is installed, a reference count is created if it doesn't already exist or incremented if it does. This is a legacy reference counting mechanism and Windows Installer also has it's own mechanism to track which products are using which files.

Reference counts for installed files are stored in the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs

For Basic MSI and InstallScript MSI project types - If 'Shared' is set to 'Yes' for a component then a reference count is created in the registry for the key file of that component when it is installed. If this reference count does not already exist then it will be created, if it already exists then it will be incremented

For InstallScript project types - If 'Shared' is set to 'Yes' for a component then a reference count is created in the registry for each file in that component when it is installed. If this reference count does not already exist then it will be created, if it already exists it will be incremented.

For all project types, if the 'Shared' setting is set to 'No', the reference count will still be incremented if it already exists. However, it will not be created if it doesn't exist already.

Why does InstallShield set components to 'Shared' by default?

As mentioned above, if you're using an MSI type project then Windows Installer has it's own methods for tracking which products installed which files (A list of components along with which products are using them is stored in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\<sid>\Components). However, it is still useful to use the legacy SharedDLL reference counting mechanism to make sure that shared files are not accidentally deleted by either your installer or another vendors.

If everyone who is developing installations for Windows correctly marks shared files with this flag then this reference counting mechanism would correctly make sure that files are only deleted when there is no applications using them. However, if a user forgets to change this setting for shared components in InstallShield then the default setting can have a large impact on what can happen on the target machine.

If an unshared file is incorrectly marked as shared then there is certain situations that can lead to this file being left behind on the machine after the product is uninstalled.

If a shared file is incorrectly marked unshared then this can lead to a shared file being deleted when it is still being relied upon by other applications. Possibly breaking multiple applications on the users machine.

As you can see, it could be far worse for the users machine if a shared file is incorrectly marked as unshared, potentially breaking multiple applications.

How to avoid inaccurate reference counts

If you are having a problem with files being left behind when your application is uninstalled, this can often be caused by not following Windows Installer best practices regarding components. For example, if you change the component code for a component without also changing the name or location of the key file and perform a major upgrade of your application, this can lead to an incorrect SharedDLL reference count that could cause that file to be left behind when your application is uninstalled.

These MSDN articles cover some of the basics that you should follow when creating or updating your MSI installer:
Defining Installer Components
Organising Applications into Components
Changing the Component Code
What Happens if the Component Rules are Broken?

If you need to clean up the SharedDLL ref count on a machine where it has become inaccurate, please see the InstallTalk blog post which is linked below.

Workaround

Here is an InstallTalk Blog post which talks about how you can use a script to clean up the reference counts on a machine where they have become inaccurate:

Cleaning Up Your Shared DLLs Registry References for MSIs

Why Are New Components Shared by Default?