How exactly are files removed during MSI uninstall?

Question

I\'d like to know what exactly happens to installed files / components during the uninstall procedure.

For the install and upgrade procedure, reliable documentation

Answer 1

There really are only a few rules that apply, but the difficulty is that they apply in a number of sometimes complicated scenarios.

A resource (a file) is removed if its component id ref count goes to zero and:

a) there is no remaining SharedDllRefcount for it.

b) the component has never been marked permanent in the installing MSI (because that makes it stick and can't be turned off).

c) the component was set to Transitive and an install/maintenance operation takes place that sets the associated property value to "false". Again, this is sticky to the system, not a project setting.

d) it has not been marked as msidbComponentAttributesShared by an install.

Permanent, transitive, component shared, and shared Dll can be set on a component.

Versioned shared files do not revert to the previous binary if product A installs version 1 and product B installs version 2 and then product B is uninstalled. By definition (it not always in practice) shared files need to support older clients.

During a major upgrade with RemoveExistingProducts (REP) at the "end", the upgrade applies file versioning rules for files, and increases the ref counts of components that are already installed (or installs the component if it's new with a ref count of 1). In this kind of upgrade the components are effectively shared with the same component ids that are already installed by the older product. When REP uninstalls the older product the ref counts are decremented.

So in the simplest case of an upgrade containing all identical component ids, no files are removed: if component ids A, B, C and D are in the older installed product and component ids A, B, C, and D are in the new upgrade then file versioning rules were applied and decrementing ref count leaves the files there, perhaps with higher version, when REP removes the older product. This why component rules must be followed with this kind of upgrade, or patch, or upgrade by reinstalling with REINSTALLMODE=vomus REINSTALL=ALL.

If component ids A, B, C and D are in the older installed product and component ids A, B, C, and E are in the new upgrade then the same happens except D will be removed because its ref count is zero now, assuming there are no other clients and the rules above do not apply.

Major upgrades with REP "early" are simple in the best case because it's an uninstall of the old product followed by an install of the new, so older versions of files could be installed, and again files are removed or not according to the above rules. None of the component ids need to be the same in the simplest case that there are no shared files used by other products.

Common issues involve setting components to permanent or Shared Dll (which is required ONLY if the file is shared with a non-MSI install). There seems to be the idea that these can be turned off by doing another install that changes them, but these are system settings, not project settings.