SharePoint “Features” in plain English

Features in SharePoint seem to be somewhat misunderstood. Maybe I just deal with too many people who do not seem willing to RTFM (and in the 2007 incarnation of SharePoint, that’s simply asking for trouble).

So.. ‘Features’. Here is the MSDN blurb..

"Microsoft Windows SharePoint Services 3.0 introduces an inherently portable and modular functionality known as a feature, which simplifies modification of sites through site definitions. A feature is a package of Windows SharePoint Services elements that can be activated for a specific scope and that helps users accomplish a particular goal or task".

Clever Workarounds Translation: "Features provide a method to add/customise many areas of SharePoint. "

Wasn’t my explanation so much simpler!

Okay, so what does that mean to me? Well, if you are a SharePoint application developer or a web designer, chances are that if you are customising a SharePoint system in a medium to large scale enterprise, you will find that the usage of features are mandated by those annoying sysadmins and governance nazis who never make anything easy for you.

Here’s your real world example to go with the explanation. We have a cast of characters…

• Webdesigner: Friendly and completely metrosexual.
• Sysadmin Nazi: Nerdy, no fashion sense and generally sullen when asked to do something.
• Site Owners: Non techy staff within various business units who have some administrative responsibility for one or more areas within the SharePoint farm. Opening a web browser and navigating to favourites is considered a technical acheivement.
• Corporate communications and PR: Determine branding and responsible for marketing related matters. Second only to senior management in terms of being technically inept.

Scenario A:

Our metrosexual webdesigner has cracked out [insert flavour of the month HTML editor here] and customised the SharePoint default page by adding a couple of CSS files with associated style images, perhaps added some flash too. ‘Just upload them to the style library in each site’, they say. Your SharePoint infrastructure manager (hereby known as sysadmin nazi), gets even more bitter and twisted than usual, having to do this task for the 35 sites currently installed on the SharePoint farm. What’s more, they only had a single shot latte that morning and hit the wall early.. so they were inconsistent with the last few sites and missed a few files.

Clever Workaround rating: "weenies"

Now no-one wants to be labeled a weenie, so let’s see if we can make this more clever.

Scenario B:

Aforementioned webdesigner is handed a SharePoint governance document by smug sysadmin nazi who mandates amongst other things, that they must package up all of their files as a ‘feature’. After grumbling about red tape, they finally accept the fact that the sysadmin nazi won’t allow their change into production and they eventually produce a feature folder. Sysadmin nazi installs the feature onto the SharePoint farm once only, then sends a mail to the 35 site owners advising them to activate the "branding feature" on their sites.  Each site owner who does so has the identical configuration modified so it is all nice and consistent.

Clever Workaround rating: "moderately clever"

So in case it’s not obvious, the nice thing about a feature is that once installed by the server/farm administrator, it can be activated by site owners on a case by case basis. Not only can it be activated, it can also be deactivated too. (Some comments with regard to this are in a forthcoming post). The thing to note is the decision to activate/deactivate a feature is made by the site owner, not the farm administrator. So the implication of this is that a feature doesn’t necessarily force change. A company with autonomous divisions may have totally different branding for their sites, and thus would not activate this feature for their sites.

Now let’s talk about updating features once they are installed.

To do this, let’s go back to our branding scenario where now, those arty farty corporate communications and branding dudes decide that the 1 pixel green line is not quite the right green and ask for it to be changed. (They get paid for this – go figure). The web designer (who by now has seen the light and offered some personal hygiene tips to sysadmin nazi) updates the CSS file and creates a new feature file for the sysadmin nazi. Sysadmin nazi installs it to the farm before heading to the vending machine for caffeine sustenance. The site administrators deactivate and then reactivate their feature on their sites at their leisure and the world is a happy place.

Okay, so at this point, let’s dive a little deeper…

To implement a Feature you add a subfolder containing a Feature definition within the Features setup directory. This is most likely located  in

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES.

Within the subfolder in this directory, you include a Feature.xml file. This is the file that SharePoint looks for when a feature is installed. It includes a GUID (all features are unique via GUID), a title and the scope of the Feature. The scope tells SharePoint whether the Feature will be made available to an entire SharePoint farm, a site collection, or a site. SharePoint uses the Feature.xml file to also identify any supporting files like ASPX pages, dynamic-link libraries (DLLs), images, etc. Using this file, you can add customised components such as new Page Templates, List, Content Types, Web Parts, Workflow and events.

Below is the list of elements that a feature can install.

1. Content Types: Contains a definition of a SharePoint content type.
2. Content Type Binding: Actually applies a content type to a document library.
3. Control: Allows you to replace existing controls on the page, such as the search or navigation with your own custom control.
4. Custom Action: You can define custom actions such as add a new menu item in "Site Actions".
5. Feature/Site Template Association: This allows you to bind a feature to a site template so that the feature is included in new sites based on that template.
6. Field: Contains a field, or column definition that can be reused in multiple lists.
7. Hide Custom Action: Opposite to "Custom Action", where you want to hide menu items.
8. List Instance: Provisions a SharePoint site with a list which includes specific data.
9. List Template: A list definition or template, which defines a list that can be provisioned to a SharePoint site.
10. Module: Deploys files which are included when provisioning sites. (This is how branding can be deployed via feature).
11. Receiver: Defines an event handler for a list, or document library.
12. Workflow: Defines a workflow for a list, or document library. 

Next, I suggest you check my other post. This illustrates the creation and install of a basic feature.  In the meantime, I leave you with this thought for the day (If you have ever watched Jerry Springer, you know what I mean )

So, why did we need to digress into features? Three reasons.

The first one is that as a designer or developer, you will find that in the future people will not accept stuff from you unless it is a feature.

The second one is that as a graduate solutions architect or business development manager, if you use this word, you might just sound like you know what you are talking about during presales meetings.

The third reason is that this notion of features is actually quite fundamental to SharePoint. So much so that the differences between WSS3 and the more fully featured MOSS2007 is that MOSS2007 has features that do not come supplied with the free WSS.