I have a product that consists of several features (A, B, C), all of which share a common windows-service component. The catch is that there is an end case: if only one specific feature is installed (feature C), with a 'legacy-mode' flag (some property that is saved in the registry), then this windows-service component either should not be installed or its startup type should be changed from 'automatic' to 'disabled'. I would prefer the 'not installed' solution to the disabled startup type solution.
In all other cases: when other features (A,B) are installed besides this feature (C), or when the 'legacy-mode' flag is not set - the windows-service component should be installed and its startup type should be set to 'automatic'.
If the product is reconfigured the condition should be reevaluated and acted upon appropriately for both scenarios.
The problem is that it is not possible to use features' install-states in the windows-service component condition, since both features' install-state and component's condition are evaluated in the same CostFinalize action (See: http://www.joyofsetup.com/2008/04/09/feature-states-in-component-conditions/) Also, using the approach of removing the component in a custom action does not work, because non-transitive components cannot be removed from existing features unless this is a major-upgrade(See http://blogs.msdn.com/b/heaths/archive/2010/02/15/test-your-conditions.aspx)
I could separate the component to a different feature of its own and try to write custom action that sets this feature's install-state based on the other features' install-states after the CostFinalize operation, but that seams to complicate the installation logic for the different scenarios (install, reconfigure, rollback, uninstall) and make it more error-prone.
What would you suggest?
