Compartir a través de

Activation Dependencies and Scope

  • Artículo

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

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 across different scopes. 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 \12\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 Feature to contain resources (for example, a content type) and a Web site 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, Windows SharePoint Services activates the second Feature.

  • If a Feature is deactivated, Windows SharePoint Services 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, provisioning of the Web site Feature (or of a site definition that contains such a Web site Feature) fails.

General Rules

  • Dependencies can work only one level deep. In other words, dependency chains are not supported. Windows SharePoint Services 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, Windows SharePoint Services 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 in a bad state. 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 in a bad state.