Shared components define shared resources. It might seem obvious, but it’s important to understand that whatever you do to a shared resource during the installation of one product affects those same resources for any other product. For example, when upgrading one product to update files shared with another product, that other product will use the newer resources such as versioned files. It’s important to test those interactions before you ship to make sure the products can work with newer resources – that the changes to those resources are backward compatible.

By default, newer versioned files will overwrite older versioned files; however, non-versioned resources like text files or registry values are always overwritten. But even versioned files exhibit different behavior when and how they are downgraded.

Continuing with the example where one product is upgraded by another MSI and shares components with another product on the system, uninstalling either of those products leaves the files at the current version. Even if both products initially installed version 1.0 of a shared file and one of those products was upgraded to include version 1.1 of that same shared file, uninstalling that product which upgraded the file to 1.1 will leave the file version at 1.1. Shared components are ref-counted and when uninstalled that reference count is only decremented.

If one or even both of those products are patched by an MSP, uninstalling that patch will downgrade that file back to version 1.0 regardless of the reference count. But Windows Installer 4.5 introduced a new feature called shared component robustness will prevent shared components marked with this bit from being downgraded when a patch is uninstalled. Windows Installer 4.5 is available as a redistributable, and this feature is available in Windows Installer 5.0 included in Windows 7 and Windows Server 2008 R2.

But if you need this functionality down-level when you can’t take a dependency on Windows Installer 4.5, you need to consider whether you prefer that files are kept at their newest version or forcibly downgraded.

• To keep files at their highest version without shared component robustness, major upgrades may be an appropriate option to consider.
• To forcibly downgrade files regardless of their reference count, patches may be a more appropriate option.

The difference in behavior could be desirable for your scenarios, but if they are not you need to plan your product deployment strategy with Windows Installer accordingly.