If you’re patching a feature or features of a Windows Installer package and see that a feature you know to be installed locally is now advertised, look for the following in your Windows Installer log:

MSI (c) (B8:C0) [12:00:00:000]: SELMGR: ComponentId ‘{01234567-89AB-CDEF-0123-456789ABCDEF}’ is registered to feature ‘FeatureA’, but is not present in the Component table. Removal of components from a feature is not supported!
MSI (c) (B8:C0) [12:00:00:000]: SELMGR: Removal of a component from a feature is not supported

The reason is documented is Changing the Product Code in the Windows Installer SDK: components can be added to new features – or existing features starting with Windows Installer 2.0 – but cannot be removed. In order to remove the component or make a change that would otherwise require a change in the component code – which is no different than removing one component and adding another – the ProductCode property must be changed, which constitutes a major upgrade.

This applies even with obsolescence and supersedence. Recall in How Patching Works that when you obsolesce or supersede a previous patch Windows Installer removes the patch transform from the in-memory view of the product. This effectively removes a component from a feature or features and violates upgrade components rules. The result is that your feature you’re trying to patch becomes advertised and it will not be patched because – as Windows Installer sees it – it’s not installed.

This makes sense if you think about it. To obsolesce or supersede another patch the new patch must contain everything from the old patch that it’s replacing. This includes not only files, registry values, and the like but components as well. By definition, if you install a new component any obsolescing or superseding patch must contain that component as well.

If you’re adding new components that are specific to individual patches, consider instead using transitive component conditions without supersedence to effectively remove the component when the new patch is installed. This is one solution I presented in A Better Way of Working with ARPSYSTEMCOMPONENT.

To catch the violation to the upgrade component rules you can pass the public MSIENFORCEUPGRADECOMPONENTRULES property or set the EnforceUpgradeComponentRules policy that will affect any install on the machine. This will cause small and minor updates to fail with either Windows Installer error 2771 if a component is removed from a feature (which also includes if a component GUID is changed since that would technically constitute a new component), or error 2772 if the feature tree is rearranged with the exception of adding a new feature as a leaf feature to an existing feature. In either case Windows error ERROR_INSTALL_FAILURE (1603) is returned from the process or Windows Installer API.