How to Create Features for Windows SharePoint Services 3.0

To customise a SharePoint (WSS 3.0) site, you'll need to understand 'Features'. The 'Feature' framework has become the recommended method of customising a SharePoint site, because it allows the ultimate flexibility, extensibility and scalability for you customisations. Charles Lee explains.

If you want to customise your WSS 3.0 implementation then you should learn about Features and how they are implemented.  A large proportion of SharePoint customisations are implemented via custom Features.  In this article I hope to explain what a Feature is and how it benefits you as a developer and/or an administrator.  I will also look at how you can create a Feature and provide a sample.

So what is a Feature then?

Basically a feature is a customisable and upgradeable SharePoint component which can be installed and activated within a farm of SharePoint servers.  Features were introduced in WSS 3.0 to address some of the significant failings in WSS 2.0 with regard to defining functionality which was to be shared by multiple sites.  They also introduced some new functionality to the SharePoint framework, such as Feature Receivers and Feature Stapling.

Microsoft themselves have used the Feature framework to modularise a large chunk of the implementation of SharePoint.  For example all of the templates, lists, libraries and other components installed when you create a Team Site within SharePoint are all made available by a series of Features.

Yes, but what actually IS a Feature?

Essentially a Feature is an XML definition for a component(s) which is to be deployed to the current SharePoint farm within a given scope.  All features live within a folder contained within the SharePoint Root.  [SharePoint Root]\TEMPLATE\FEATURES.  This folder contains a sub-folder for every feature that has been deployed to SharePoint.

Note: The SharePoint Root is the new name for what used to be referred to as the 12 Hive.  This is the directory located at C:\Program Files\Common Files\Microsoft Shared\web server extensions\12, although in SharePoint Foundation 2010 this will be 14 not 12.

Each Feature’s folder requires a single xml file called feature.xml, this is needed to tell SharePoint some basic details about the feature such as its Title, Description and Scope as well as assigning the feature with a unique Id.

A sample feature.xml might look something like this:

Feature scopes

You may have noticed that the feature detailed above has an attribute called Scope.   The Scope of a feature dictates the extent to which the changes which are implemented by the feature will spread.  For example a Feature scoped to the ‘Site’ will have an effect on the current Site Collection and all sites within that Site Collection.  Whereas a ‘Web’ scoped feature (like the sample above) would only affect the current site.  There are four different scopes available to Features and these are listed below.


The feature created in our sample above will not actually do anything, because the feature definition file is only used to define the feature and not the actions taken when a feature is activated.  In order for a feature to actually ‘do’ something it must either have an Element Manifest file or else implement a Feature Receiver.

The Element Manifest

An element manifest is another XML file which may be used within a Feature to define the elements which will be created and deployed.  I am not going to cover this file in detail as there is a huge amount which can be deployed using an element manifest.  A sample element manifest to deploy an instance of a list would look something like this:

More detail on the element manifest format for specific items can be found on MSDN.

Once you have created an Element Manifest then you need to register this in your Feature definition so that SharePoint is aware of the file when the Feature is activated.  This is done by using the ElementManifests element within the Feature definition.  Assuming your elements file is called elements.xml then your feature definition would now look something like this (highlighted section has been added):

Feature Receivers

Essentially a Feature Receiver is a very specific type of event receiver which is geared up specifically to receive events raised by the Feature framework.  There are typically four events that you may wish to intercept and take action upon, each one occurs at a different phase of the features lifecycle.


From the stages above you should notice that you cannot intercept Features before they are installed or activated.

In order to create a Feature Receiver you need to create a new class which inherits from Microsoft.SharePoint.SPFeatureReceiver and implements all four of the events shown above.  This class then needs to be signed and compiled and the resulting assembly should be deployed to the GAC. 

Note: The assembly containing your Feature Receiver can (and should) be deployed using a Windows SharePoint Services Solution Package (WSP) file.  However this is outside of the scope of this article.

By using a Feature Receiver you can essentially employ the power of the SharePoint API to perform whatever action you like.  Each event which you override in your instance of the feature receiver will have one input parameter which is an instance of the Microsft.SharePoint.SPFeatureReceiverProperties class.  You can use these properties to access details of the Farm, Web Application, Site Collection or Site for which this feature is being activated or installed.

An example Feature Receiver which would update the description of the current site would look something like this:

Note: The above class is in no way optimal and is just a demonstration of the technique.  This class expects the feature to be running within a ‘Web’ scope, if it is not then the first line which retrieves the SPWeb object will fail.  It’s also worth noting the use of the property bag on the SPWeb object. This is a very useful technique in managing features as it allows you to restore any properties you may have changed to their original value.

In a similar way to the Element Manifest, once we have created a Feature Receiver we need to register this with Feature definition file so that SharePoint knows to call this receiver during the installation and activation.  This is done via two additional attributes on the Feature element.

  • The ReceiverAssembly attribute should contain the fully qualified assembly name for your compiled assembly.  The fully qualified assembly name is made up as follows:

    AssemblyName, Version, Culture,PublicKeyToken

    This is sometimes referred to as the four-part name for an assembly.

  • The ReceiverClass attribute should be the fully qualified name of your Feature Receiver class, this is made up of:


Note: These two attributes are probably the most common cause of issues when deploying a feature so pay close attention to them if you have any problems.

Your Feature Definition will now look something like this:

If you are having trouble establishing the four-part name for your compiled assembly then you can always open the file in Red Gate’s .Net Reflector product and click on the name of your assembly in the tree. The four-part name is displayed as shown below (in red.)


Installing and Activating a Feature

Once you have created an appropriate Feature Definition and appropriate Element Manifests and/or Feature Receiver (you can have a combination of both) then you need to install your feature within SharePoint.  This is done using the installfeature operation of STSADM.exe

stsadm.exe -o installfeature -name MyFeature

The name parameter MUST be the name of the containing folder within the FEATURES folder as this is actually the internal name of the Feature.  If you try to use the value of the Title attribute from your feature.xml then this command will fail (unless they happen to be exactly the same of course.)

Installing a feature makes it available to activate from the browser interface.  Depending on the scope of your feature you will have to go to the specific settings page to it.  In the case of your ‘Web’ scoped feature this will be Site Settings > Site Features.

Find your feature in the list and click on the ‘Activate’ button.  Your feature is then activated within the specified scope.  Any elements specified will be installed and any code specified in your Feature Receiver will execute.

You have now completed all the necessary steps to create and deploy a SharePoint feature.  As you can see this is a very powerful framework and it is highly recommended that you use this method to deploy all customised components into a SharePoint environment. 

I would like to just discuss a couple of additional elements that are useful when dealing with SharePoint features. 

Feature Dependencies

As part of its support for the modularisation of components SharePoint allows features to activate other dependent features.  This means that features can keep to the old adage:

“Do one thing and do it well!”

In fact a feature could literally just activate a series of dependant features and nothing else.  There are examples of this approach in the OOTB WSS 3.0 features (take a look at the feature called ‘TeamCollab’.)

To create a feature dependency you simply add some code similar to the following to your feature.xml

Replacing [GUID] with the Id of the Feature of the dependent feature.

Feature Stapling

Once you have created your fantastic feature you may want to apply this to all new sites going forward.  Now assuming you always use a custom site definition for each and every new site in your environment then this may be possible.  However it’s unlikely.  This issue is solved with Feature Stapling as you now have the ability to ‘staple’ your feature to an existing site definition.  Once stapled then any new sites based on this template will automatically activate your Feature.

This is achieved by creating a new Feature, commonly named after the Feature that it staples suffixed with ‘Stapling’ so in our example a stapling feature would be called MyFeatureStapling.

This feature should declare an Element Manifest which uses the FeatureSiteTemplateAssociation site element. An example which would ‘staple’ your new feature to the blank site template would look like this:

If the feature containing this Element Manifest was then deployed then any new sites based on the site definition STS#1 (which is the name of the blank site template) will automatically have your feature activated.   If the stapling feature is deactivated then the feature will no longer be stapled to that site definition.

The Future

We are only just around the corner from the public release of SharePoint Foundation 2010 (May 12th 2010), which is the new name for what would have been WSS 4.0.  The approach to developing Features as far as I am aware has not significantly changed.  However there has been a significant improvement in the tooling on offer through Visual Studio 2010, including a new Feature Explorer.  Amongst other things this offers a menu driven process for creating and configuring Feature Definitions, Element Manifests and Feature Receivers.  I will write more on this in a future article.

That’s All Folks…

As you can tell from this very quick tour of the Feature Framework there is a lot of flexibility built into this method of installing your customisations.  I would urge you to explore in detail the various site elements which can be deployed via the Element Manifest as this is by far the cleanest method of deploying components into a SharePoint environment.  It’s virtually self-documenting unlike the API approach via Feature Receivers.  You’ll often find however that you need to use a combination of both approaches to feature development as some things are very hard to achieve with the declarative approach (Element Manifests.)

Next time around I plan to be looking at an introduction to using MOSS 2007 for creating public facing internet sites (not WSS 3.0 as there is no support for the Web Content Management features unless you have MOSS.)