Activation Dependencies and Scope
Applies to: SharePoint Foundation 2010
A Feature activation dependency expresses a requirement in the relationship between two Features. You can express activation dependencies either for Features of the same scope or for Features at a higher scope. A cross-scope activation dependency exists when a Feature at a particular scope has a dependency on another Feature that is at a different scope. An example of a cross-scope activation dependency would be a Web site–scoped Feature being dependent on a site collection–scoped Feature.
You generally use activation dependencies for two purposes:
Feature grouping concepts When one Feature is activated, other Features can also be activated. For example, when the default "team collaboration" Feature (in %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES\TeamCollab) is activated, it uses activation dependencies to activate various other Features. When you activate the team collaboration Feature, it activates the dependent Features, and the specified list templates are made available. When you deactivate the Feature, the dependent Features are deactivated if no other Features depend on them, thereby making the list templates unavailable.
Feature resource guarantees You may need a site collection-scoped Feature to contain resources (for example, a content type) and a Web site-scoped Feature to contain an implementation. You can use an activation dependency to ensure that both Features are activated.
Activation Dependency Rules
Activation dependencies must abide by certain rules to avoid, for example, circular dependencies, dependency chains that limit performance, and so on.
Same-Scope Rules
If a Feature is dependent on another Feature at the same scope, and the second Feature is not activated when the first one is activated, Microsoft SharePoint Foundation activates the second Feature.
If a Feature is deactivated, SharePoint Foundation deactivates a same-scope dependent hidden Feature when the last visible Feature that has an activation dependency on that hidden Feature is deactivated.
Cross-Scope Rules
Cross-scope activation dependencies are not supported if the Feature depended upon is at a more restrictive scope. For example, a site collection–scoped Feature cannot have an activation dependency on a Web site–scoped Feature.
Feature activation dependencies are not supported across scopes if the Feature that is depended upon is not visible. In other words, a Web site–scoped feature cannot be dependent on a site collection–scoped Feature that is not visible in the user interface.
If the Feature that is depended upon is not activated, activation of the depending Feature fails. For example, if a Web site–scoped Feature depends on a site collection–scoped Feature that is not activated, activation of the Web site-scoped Feature (or of a site definition that contains a Web site-scoped Feature) fails.
General Rules
Dependencies can work only one level deep. In other words, dependency chains are not supported. SharePoint Foundation does not support more than one level in activation dependencies if the last Feature is visible—that is if a visible Feature depends on a second visible Feature that in turn depends on a third visible Feature. However, SharePoint Foundation does support more than one level in activation dependencies if a visible Feature depends on a second visible Feature that in turn depends on a hidden Feature.
You can target an activation dependency against hidden or visible Features, but hidden Features cannot have activation dependencies. The Hidden attribute on the Feature element determines whether the Feature is displayed in the user interface.
When more than one Feature has a dependency on a given Feature, keep in mind the danger of leaving one of the depending Features without the required Feature dependencies. For example, assume that a visible, site collection–scoped Feature named Feature B depends on a hidden, site collection–scoped Feature named Feature A, and that a third visible, Web site–scoped Feature named Feature C is also dependent on Feature A. Deactivating Feature B also deactivates Feature A, thus leaving Feature C without the required Feature dependencies.