Feature Stapling Lifecycle

The actual lifecycle of the feature stapling process is not documented actually documented anywhere. The following information has been solely gathered based on my testing and experimenting with the process.

If we step back and look at a site definition file we know that the GLOBAL#0 site template is applied to all site definitions. Many of the Microsoft provided site definitions enable functionality through the use of the feature system. If you open up the STS site definition ONET.XML file, you will see two sections near the bottom called SiteFeatures and WebFeatures:

You will notice that in many of the Windows SharePoint Services site definition files the ListTemplates section is not populated with anything; they use list definition features instead. As you can see, the Team Site site definition points to a feature called TeamCollab. This feature makes list definitions available to the web that is being created.

So what does this all mean when it comes to feature association? The important thing to remember here is that any feature receivers you develop and associate to a site definition will get executed before any of the lists on that site have been provisioned. However, anything provisioned via the Global Site Definition will be available to your feature receiver.

This is not a problem if you simply want to create new lists, libraries, etc. However, if you are attempting to manipulate any lists that are part of the site definition you are associating with you will find yourself looking at a System.ArgumentException stating “Value does not fall within the expected ranged.”

The following image shows what happens when I create a Team Site that has my custom feature receiver associated to it:

Solution

We have already determined that feature receivers make it extremely easy for a developer to extend and customize out of the box site definitions without touching the files. But we run into a road block when we attempt to customize the lists and libraries that are part of that site definition.

One way I have used to get around this is to simply delay the customizations until after the site has completely provisioned.

The following is an example using the ThreadPool.QueueUserWorkItem method:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
    using (SPWeb web = (SPWeb)properties.Feature.Parent)
    {
        ThreadPool.QueueUserWorkItem(new WaitCallback(RunProcess), web.Url);
    }
} 
 
private void RunProcess(object state)
{
    Thread.Sleep(5000); 
 
    string url = (string)state;
    using (SPSite site = new SPSite(url))
    {
        using (SPWeb web = site.OpenWeb())
        {
            // at this point, the site should be provisioned
            // and we will now have access to all lists on it
            SPList list = web.Lists["Shared Documents"];
            list.Description = "Updated from Feature Receiver";
            list.Update(); 
 
        }
    }
}

Why are we running on a different thread? Well, this allows the site provisioning process to complete and then we come back in a few seconds later to customize it as needed. Of course, the sample above is not 100% perfect. What happens if it takes 10 seconds to provision a site – well the method above would fail out.

A more elegant way would probably be to check the SPWeb.Provisioned property which is False until after the provisioning process has completed; but you get the general idea.

Summary

Hopefully this two part series has given you the necessary information needed to get started using SharePoint Feature Stapling and what potential issues to watch out for. There is many resources out on the Internet that cover other aspects of Feature Stapling, but I’ll list a few here for your reference:

MSDN: Feature Stapling

MSDN: Feature Event Receiver

http://blogs.msdn.com/cjohnson/archive/2006/11/01/feature-stapling-in-wss-v3.aspx

http://www.sharepointnutsandbolts.com/2007/05/feature-stapling.html

The focus of this article is going to be on a concept called Feature Stapling. Most, if not all, SharePoint developers know that Microsoft frowns on modifications to the “Microsoft” owned files that support SharePoint. If you modify these files you run the risk of your changes being broken with the installation of a service pack or hot fix. Sometimes this was your only option when attempting to customize SharePoint back in the WSS 2.0 days. The following KB article that outlines the supported / unsupported scenarios when it comes to modifying the default site definition files (http://support.microsoft.com/kb/898631).

Feature Stapling allows you to create a feature and then associate it with any site definition without ever touching the site definition files themselves. Your feature will be executed when the site is being provisioned.

As you read this series of articles I hope to explain how Feature Stapling works through the creation of a working feature and feature stapling example. I will also touch on some important points and considerations you need to be aware of about when in the life cycle of a site being provisioned your feature will be executed.

Feature Stapling

Feature Stapling is achieved through the creation of another feature that defines the association of your regular Feature and the site definition you want to “staple” it too. In other words, you need to create two Features to achieve a complete Feature Stapling implementation.

Creating Feature

There are many different recommendations on how to go about creating SharePoint Features within Visual Studio from the layout to the deployment. In this article, I am going to use the method that works best for me. I use Visual Studio 2008, a class library, and WSP Builder (http://www.codeplex.com/wspbuilder). WSP Builder is what I ultimately use to generate my solution file; however, it does have some features such as Copy to 12 Hive, and Recycle Application Pools that I used while creating my Feature.

In this scenario, I want to capture the Title and URL of any site that was created using the Team Site template in a central location.

Step 1: Create the 12 hive folder structure down to my actual Feature, created a strong named key, and added a reference to the Microsoft.SharePoint.dll assembly.

The following is a screen capture of my project in Visual Studio:

Step 2: Add a new class file in the root of the project folder called SampleFeatureReceiver.cs and use the following code:

using System;
using Microsoft.SharePoint;
 
namespace Liebrand.Sample
{
    public class SampleFeatureReceiver : SPFeatureReceiver
    {
        public override void FeatureActivated(SPFeatureReceiverProperties properties)
        {
            using (SPWeb web = (SPWeb)properties.Feature.Parent)
            {
                if (web.IsRootWeb)
                    return;
 
                using (SPSite site = web.Site)
                {
                    using (SPWeb rootWeb = site.RootWeb)
                    {
                        SPList createdSites = GetProvisionedSitesListId(rootWeb);
                        SPListItem newItem = createdSites.Items.Add();
 
                        newItem["Title"] = web.Title;
                        newItem["Url"] = web.Url;
                        newItem.Update();
                    }
                }
             }
        }
 
        private SPList GetProvisionedSitesListId(SPWeb rootWeb)
        {
            try
            {
                SPList list = rootWeb.Lists["Provisioned Sites"];
                return list;
            }
            catch (ArgumentException)
            {
                Guid listId = rootWeb.Lists.Add("Provisioned Sites",
                    "This list contains all the sites that have been provisioned.",
                    SPListTemplateType.GenericList);
 
                SPList list = rootWeb.Lists[listId];
 
                list.Fields.Add("Url", SPFieldType.URL, false);
                SPField field = list.Fields["Url"];
 
                SPView view = list.DefaultView;
                view.ViewFields.Add(field);
                view.Update();
 
                list.Update();
 
                return list;
            }
        }
 
        public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
        {
        }
 
        public override void FeatureInstalled(SPFeatureReceiverProperties properties)
        {
        }
 
        public override void FeatureUninstalling(SPFeatureReceiverProperties properties)
        {
        }
    }
}

This code basically adds the URL of the site being provision to a listed called Provisioned Sites that is located in the root site. If the list is not found, the list is created.

Step 3: Add a new XML file called feature.xml to the feature folder and paste the following contents:

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="2B3451F0-BC93-41A4-9FAD-3A81861D651A"
         Title="Liebrand Feature Sample"
         Description="This is a feature that will be used to demonstrate feature stapling."
         Scope="Web"
         Hidden="False"
         Version="1.0.0.0"
         ReceiverAssembly="Liebrand.Sample, Version=1.0.0.0, Culture=neutral, PublicKeyToken=057a20dd10f3b267"
         ReceiverClass="Liebrand.Sample.SampleFeatureReceiver">
</Feature>

Creating the Stapling Feature feature

At this point, our primary Feature is ready to go. The last step is to simply create another Feature that will associate my LiebrandSample Feature with the Team Site site definition.

Step 1: Add another folder under the FEATURES folder called LiebrandSampleStapler and add a file called feature.xml then paste the following contents into it:

<?xml version="1.0" encoding="utf-8" ?>
<Feature xmlns="http://schemas.microsoft.com/sharepoint/"
         Id="C384D136-79A8-48BD-AF73-C630547F4D8E"
         Title="Liebrand Sample Stapler"
         Description="This feature staples the LiebrandSample feature to the Team Site site definition."
         Scope="Farm"
         Hidden="False"
         Version="1.0.0.0">

  <ElementManifests>
    <ElementManifest Location="elements.xml" />
  </ElementManifests>

</Feature>

Step 2: Add a XML file called elements.xml to the LiebrandSampleStapler folder and paste the following:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <FeatureSiteTemplateAssociation Id="2B3451F0-BC93-41A4-9FAD-3A81861D651A"
                                  TemplateName="STS#0"/>
</Elements>

The ID attribute in the FeatureSiteTemplateAssociation element should match the ID of the Feature we created at the beginning of this article. The TemplateName attribute should match the site definition name and configuration ID found in the webtemp.xml file located in C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\1033\XML. Since we want to associate our new Feature to all Team Site sites we specify STS#0. STS is the name of the Template and 0 is the configuration ID for the Team Site.

At this point we are ready to deploy our new features and test it out.

Deployment

First build your project to insure you have no build errors and to generate the assembly Liebrand.Sample.dll.

To deploy these new Features using WSP Builder simply,

• Right-click on the project name and select WSPBuilder, then click Copy to GAC. This will copy the assembly into the Global Assembly Cache.
• Right-click on the project name and select WSPBuilder, then click Copy to 12 hive. This will copy the 12 hive folder structure in your project to the SharePoint 12 hive folder

• Install and activate the Features by running the following commands:

stsadm -o installfeature -name LiebrandSample

stsadm -o installfeature -name LiebrandSampleStapler

Test

At this point you can create a new sub-site using the Team Site template and you should see a new list called Provisioned Sites get created at the root site with a new entry added that will point back to the site you created.

After creating 3 team sites, this is what the Provisioned Sites list looked like:

Summary

Features Stapling offers a great way for developers to extend, change, or customize the out-of-the-box site definitions without ever touching them. Hopefully this article gives you an idea of where you can utilize Feature Stapling. In the next article of this series, I am going to cover when Feature Stapling occurs in the creation of a site and some key points you need to be aware of when it comes to what elements are available to you when your feature is executed.