Feature Dependency Order

I recently ran across a helpful blog entry by the Norwegian MCS Information Worker team, which succinctly outlines the relationships between features, in terms of activation dependencies across scopes and between hidden and visible features. http://blogs.msdn.com/mcsnoiwb/archive/2008/05/28/hidden-features-and-dependencies.aspx

I’ve tried to visually represent some of the scenarios they’ve outlined:

This scenario does not work, because if you try activate the feature at the web level before the feature at the site level has been activated, it will throw an error in the UI saying you need to activate the feature at the site level, but there’s no way to do that via the UI because the site feature is hidden.

This scenario does not work, because a hidden feature cannot activate another hidden feature. (The List Definition feature could activate the Content Type feature, but the process would fail when the Content Type tried to activate the Columns feature.)

This process will work, as long as the Activation Dependency elements in the Feature definition are listed in the correct order. In this case, the List Definition feature would have an activation dependency on the hidden Content Type feature, and then the hidden Columns feature.

A better way to activate features might be like this: A single visible feature at the site level rolls up all hidden features that need to be activated at the site level. Another visible feature at the web level rolls up all the features that need to be activated at the web level. If the roll up feature at the web level has the site feature as its first dependency, because the roll up feature at the site level is visible, the user will get a meaningful message in the UI notifying them that they need to activate that feature. Once they do that, and they try to activate the roll up feature at the web level again, it will automatically activate the hidden features at the web level.