|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.|
Working with Features
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
Features reduce the complexity involved in making simple site customizations, and are robust when upgrades are applied to a deployment. Features eliminate the need to copy large chunks of code to change simple functionality. Features thus reduce versioning and inconsistency issues that may arise among front-end Web servers. Features make it easier to activate or deactivate functionality in the course of a deployment, and administrators can easily transform the template or definition of a site by simply toggling a particular Feature on or off in the user interface. Features provide the following capabilities:
Scoping semantics for determining where custom code runs
Pluggable behavior for installing or uninstalling Features within a deployment
Pluggable behavior for activating or deactivating Features at a given scope
A scoped property bag for storing data required by a Feature within its scope
The basis of a unified framework for distributed deployment of Windows SharePoint Services solutions
To implement a Feature you add a subfolder containing a Feature definition within the Features setup directory (Local_Drive:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES). The Feature subfolder includes a Feature.xml file that defines the base properties of the Feature and lists elements bound to it, such as XML files containing element manifests and any other supporting files. A Feature folder may contain only a Feature.xml file, or it may contain a Feature.xml file and any number of supporting element files, including XML files, but also .aspx, .htm, .xsn, .resx, .dll, and other file types.
When you create a folder within the Features directory through Windows Explorer by right-clicking a folder, pointing to New, and then clicking Folder, the new folder does not have inherited permissions. If you deploy a Feature in the folder, then some Windows SharePoint Services pages, such as for site settings or list views, throw an exception. You can fix this problem by right-clicking the new folder, click Properties, click Security, and then click Advanced. On the Permissions tab, delete uninherited permissions from the folder. You can also fix this problem by creating the new folder at the command prompt through the md command.
After creating the Feature folder, you can install and activate the Feature through command-line operations of stsadm.exe, or through the object model. You can also activate a Feature through the user interface. Installing a Feature makes its definition and elements known throughout a server farm, and activating the Feature makes the feature available at a particular scope.
The Feature element is used in a Feature.xml file to define a Feature and to specify the location of assemblies, files, dependencies, or properties that support the Feature. A Feature includes a Feature.xml file and any number of files describing individual elements. Another Feature element from a different schema is used in an Onet.xml file to specify that a Feature be activated within a site definition.
Items that were previously contained within a large site definition file have been broken out as separate elements within Features. An element is an atomic unit within a Feature. A Feature.xml file typically points to one or more XML files whose top-level <Elements> tag contains definitions for elements that support the Feature. Elements in Windows SharePoint Services 3.0 often correspond to what were discrete nodes in the Onet.xml or Schema.xml file of the previous version. There are several types of element—for instance, a custom menu item or an event handler.
A Feature could provide, for example, a "My Favorite Items" functionality that includes the following elements:
A custom list that stores, per user, a list of favorite items, which is created as a single hidden list per workspace when the Feature is enabled.
A custom menu item that is attached to all lists, called "Add to Favorites," which adds an item to the Favorites list.
A Web Part that implements usage and link tracking to display the user's top 10 favorites at the top.
Each element of the Feature, by itself, may not be very useful, but when you enable the Feature on a site, all these elements add up to a complete solution.
For specific information about the file format and XML elements used in the Feature.xml file, see Feature.xml Files. For information about how features affect the file format of the ONET.XML file in a site definition, see Site Definition (Onet.xml) Files.
Windows SharePoint Services supports only low-order ASCII characters, and no spaces, for Feature folder and file names.