Why is My Feature Advertised?

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.