Basics of SharePoint Features

SharePoint feature acts as container of the functionalities or customizations. These functionalities/ customizations are created either by declaratively or programmatically and can be made available or unavailable by activating or deactivating the feature.

SharePoint feature has following scopes

1.       Farm - feature contained functionality becomes available to whole farm

2.       Webapplication - feature contained functionality becomes available to the web application in which feature is activated

3.       Site  - feature contained functionality becomes available to the site collection in which feature is activated

4.       Web - feature contained functionality becomes available to the sub-site in which feature is activated

The SharePoint feature contains following type of files

1.       Feature manifest - Feature.xml

2.       Element manifest - Element.xml

3.       Element File - any other file than feature.xml and element.xml. It can be .master, .webpart, .aspx, resx, .css etc file.

Feature Manifest

The below figure shows the attributes of feature manifest file apart from UpgradeSolutions.

Figure 1 : Feature Manifest

Element Manifest

Element manifest file contains CAML definitions of various SharePoint content elements. Some of them are mentioned below.

Figure 2 : Element Manifest

Following table lists down the content elements with their purposes.

Content Element Tag	Purpose
<ContentType />	Creates content type
<ContentTypeBinding />	Binds the content type with list instance
<Control />	Adds control into the delegate controls present in master page
<CustomAction />	Create link at predefined SharePoint locations Create buttons in ribbon
<CustomActionGroup />	Creates group for custom actions
<FeatureSiteTemplateAssociation />	Staples the features to existing site definitions
<Field />	Creates Site column
<HideCustomAction />	Hides the existing custom actions link
<ListInstance />	Creates the list instance
<ListTemplate />	Creates custom list definitions
<Module />	Uploads any file to SharePoint document libraries
<PropertyBag />	Creates property in the property bag collection for the list item, file, folder, or website
<Receivers />	Registers the SharePoint list related event
<WebTemplate />	Create feature based site template
<Workflow />	Defines custom workflow schema
<WorkflowActions />	Defines custom workflow activity
<WorkflowAssociation />	Associates the workflow with list/ content types

Few Design level considerations

1.       Feature must be scoped at appropriate level so that feature functionality is only available in desired places.

2.       In case there are multiple functionalities that need to be added through the feature, then it is better to have separate feature for each one of them so that you can individually turn on/off those through feature activation/deactivation. This will ensure one functionality is not affecting other.

e.g. Consider a feature which adds a web part to the page layout using AllUserWebpart element. Activating this feature multiple times results in multiple web part addition to the page layout. Hence if you are adding a new functionality in the same feature, you will need to deactivate/ activate it. This in turn will result in multiple web parts addition to the page layout which is undesired.

3.       The feature can be made configurable using the feature property bag collection

e.g. Suppose you want to create a feature which applies your custom master page to the site in feature receiver code. Then it is better to add a property to the feature as shown in below figure.

Figure 3 : Feature Properties

This property then can be used to apply the master page in feature receiver code

Figure 4 : Feature Receiver

4.       Feature dependencies and hidden features

Feature dependencies always work in hierarchical manner. If you make the parent feature hidden then it will get auto activated on dependent feature activation.Good read about feature dependencies here.

Feature Receiver
Feature supports following events.

public class DemoEventReceiver : SPFeatureReceiver     {         //Raised after a feature has been activated.         public override void FeatureActivated(SPFeatureReceiverProperties properties)         {         }         // Raised before a feature is deactivated.         public override void FeatureDeactivating(SPFeatureReceiverProperties properties)         {         }         // Raised after a feature has been installed.         public override void FeatureInstalled(SPFeatureReceiverProperties properties)         {         }         // Raised before a feature is uninstalled.         public override void FeatureUninstalling(SPFeatureReceiverProperties properties)         {         }         // Raised when a feature is upgrading. This event is newly added in SharePoint 2010          public override void FeatureUpgrading(SPFeatureReceiverProperties properties, string upgradeActionName, System.Collections.Generic.IDictionary<string, string> parameters)         {         }     }

Deployment challenges

Following are the feature operations not supported in solution upgrade (stsadm upgradesolution command). 

• Removing old Features in a new version of a solution.
• Adding new Features in a solution upgrade.
• Updating or changing the receiver assembly for existing Features in a new version of a solution.
• Adding or changing Feature elements (Element.xml files) in a new version of a solution.
• Adding or changing Feature properties in a new version of a solution.
• Changing the ID or scope of old Features in a new version of a solution.
• Removing Feature elements (Element.xml files) in a new version of a solution.
• Removing Feature properties in a new version of a solution.

One can say, a simple workaround for overcoming these challenges is to retract, delete and redeploy the wsp package. But beware, there is a catch! You should before deactivate/ uninstall the features which are supposed to be removed or whose feature Ids are to be changed. Otherwise, it leaves dangling feature entries in SharePoint content database, which will give troubles especially when you are upgrading from MOSS 2007 to SharePoint 2010. You can find such dangling features either by running the stsadm preupgradecheck command or closely monitoring the SharePoint ULS logs.

Now SharePoint 2010 has brought a very interesting functionality called Feature Upgrade which comes into picture when stsadm upgradesolution command is used. It addresses some of the challenges mentioned above. Nobody explains this functionality better than The Chris Obrien in his FeatureUpgrade blog series.

The SharePoint features can be forcefully activated through stsadm/ powsershell scripts. But you should not use it unless it is must.

God…you there? ….are my prayers loud enough?