Site Provisioning Order

If you ever have gotten stumbled over your features not activating as expected or dependencies not working,  that might have to do with site provisioning order.

SharePoint provisions in the following order:

1. global onet.xml
2. SPSite scoped features defined in onet.xml, in the order they are defined in the file.
3. SPSite scoped stapled features, in quasi random order
4. SPWeb scoped features defined in onet.xml, in the order they are defined in the file.
5. SPWeb scoped stapled features, in quasi random order
6. List instances defined in onet.xml
7. Modules defined in onet.xml

Implications:

1. SPSite features should never depend on anything provisoned by an SPWeb feature.  Since generally spweb scoped features are always provisioned after SPSite scoped features, the SPSite scoped feature can't rely on a resource that gets provisioned in an SPWeb scoped feature.
2. Features can't depend on lists or files provisioned in onet.xml.  Features are provisioned before the actual lists and files which are contained in onet.xml.    However, list instances and files defined in onet.xml can take dependencies on list definitions or list instances defined in features.
3. List instances and modules defined in onet.xml or within web scoped features listed in the <WebFeatures> tag of onet.xml should never take any dependencies on features that are "stapled".  Stapled features are transient and may not be stapled if the admin adjusts their configuration.

Comments

• Anonymous
  May 28, 2008
  What is feature stapling and how we can do that in WSS 3.0? You can use Feature stapling to effectively

• Anonymous
  December 23, 2008
  This is great info, but it doesn't mention where a FeatureReceiver fits in the order. Presumably it depends on how you've stapled it? However, I suspect that it might also be random. For example, you activate publishing in the onet.xml, and then check IsPublishingWeb() in a feature stapled to the template. In this case, it is probably random as to whether this will return true or false based on e.g. what else the server is up to. I certainly seem to be getting random results when I've experimented. I have seen people add this to their code to get around the issue!!: bool pubWeb = false;   while (!pubWeb)   {     if (PublishingWeb.IsPublishingWeb(web))     {       pubWeb = true;     }   }   It seems to me that the safest thing is not to mix and match feature activation methods, because you cannot depend on the order they will fire. It's better to choose one place e.g. onet.xml or featurereceiver and put all your activations in one location where you can be sure of the order that they are going to fire.

• Anonymous
  January 30, 2009
  The FeatureReciever events, ie featureactivated, is triggered when the feature is activated, so yes it depends on how you stapled it. In our SiteConfigurator feature on Codeplex, we have omitted this problem by giving each feature an "order" attribute (integer value), and active the features accordingly.

• Anonymous
  February 18, 2009
  What do you mean by "quasi random order"? I'm having an issue in that I have two web-scoped features (Feature A = Several list instances, Feature B = adding a module to one of the lists) which are both stapled to one of the standad Site Definitions. Feature B depends on Fetaure A. I've put the activation dependancies in but it seems that my stapling feature is trying to activate Feature B before feature A has fully activated and the lists instances have not been created. However I have had this working, but it seems to have broken since adding a third feature, hence me thinking that somewhere a new sequence has been set in the stapling feature.

• Anonymous
  February 18, 2009
  >> What do you mean by "quasi random order"? I mean it is not a order you can control 100 %, unfortunately. However I have adressed this issue in our SiteConfigurator tool on codeplex.com - http://www.codeplex.com/spsiteconfigurator