Designing SharePoint Solutions and Features -
     SharePoint Features

Ramona Maxwell’s study notes, ©2011 All rights reserved

My first question about SP2010 Features was, how do these differ from Web Parts? Features are smaller and less powerful, yet invaluable in their simplicity and scope. Web Parts controls are reusable and connectable building blocks, whereas a Feature might be implemented to perform a task and then cleared from memory. You might use one to call a list, but like the person delivering your pizza or flowers, they don't need to stand in the hall once the task is done. A feature, once installed, becomes available throughout the SP2010 installation but to use it you must activate it within a certain scope. Features are necessary to extend the functionality of the SP2010 UI partly because Microsoft doesn't support alteration of the default site and area definitions within SP2010. If you do so, even if your customization survives for a time, it may be wiped out by updates to those areas Microsoft is reserving for its program structure.

A Feature can also be compared to a bucket that holds all the odd little nuts and bolts of a task; MSDN says these might include, "templates, pages, list definitions, event handlers, workflows, customizations, and other objects." Within your Feature's directory you can place other needed resources such as images, scripts or style sheets. One feature can depend on another's capabilities as long as the dependent feature is at a lower scope than the one it depends upon. Scopes step uptwards from Site at the bottom up to Site Collection, Web Application and then Server Farm as the broadest scope. Features have a modestly sized set of classes within the Micrsoft.SharePoint Namespace so that you can manipulate them using the SharePoint Foundation object model. These include event handlers that can trigger actions based on a Feature being installed, uninstalled, activated, deactivated or upgraded.

The Feature.xml file and a Feature elements file are the two supporting structures that define the Feature's scope, dependencies and assets. There is a little conflict in the MSDN documentation where one sentence says the Feature elements file can have any file name, but another page has a highlighted yellow note warning that "SharePoint Foundation supports only low-order ASCII characters, and no spaces, for Feature folder and file names.", and indeed the code examples used the old-fashioned file naming conventions.

Return to