This third post is about creating and using Features in a general sense. Creating Features for each specific element will be the subject of later posts. Check the first post SharePoint 2007 Deployment: Overview for an introduction and the series index.
A Feature can be activated or deactivated in a specific scope, and there are four different scopes:
- Farm – The elements will be deployed at the farm level. To activate or deactivate a farm-scoped Feature, go to Central Administration, Operations section, and click on Manage Farm Features in the Global Configuration group.
- Web Application – The elements will be deployed at the web application level. To activate or deactivate a web application-scoped Feature, go to Central Administration, Application Management section, and click on Manage Web Application Features in the SharePoint Web Application Management group.
- Site Collection – The elements will be deployed at the site collection level. To activate or deactivate a site collection-scoped Feature, go to the root web site settings, and click on Site Collection Features in the Site Collection Administration group. You must be a site collection administrator to see this setting.
- Web Site – The elements will be deployed at the web site level. To activate or deactivate a web site-scoped Feature, go to the web site settings, and click on Site Features in the Site Administration group. You must have ManageWeb permissions (for instance, being a site administrator) to see this setting.
Each type of element can be deployed to one or more of these scopes. When describing each element type, I will specify to which scopes they can be deployed to.
To create a Feature you must create a XML file named
feature.xml which contains all the general configurations for the Feature and the references to all the files that describe the Elements contained in the Feature. Below is an example of a
feature.xml file that uses all possible attributes, just for demonstration purposes. Required attributes are printed in bold.
<?xml version="1.0" encoding="utf-8" ?>
Description="My Feature includes several elements."
ImageUrlAltText="My Feature Icon"
ReceiverAssembly="MyFeatureReceiver, Version=18.104.22.168, Culture=Neutral, PublicKeyToken=3f5df55c01ba1c99"
<Property Key="MyProperty" Value="MyValue" />
Tip: To make things easier when creating these files in Visual Studio 2005 (or later), you can use the
wss.xsd schema file, included with SharePoint (usually in
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML), to enable Intellisense.
<Feature> element is the root element of the
feature.xml file and it has several possible attributes, although not all of them are required:
Id (required): Unique identifier for this feature (GUID).
Scope (required): Scope in which the Feature will be activated/deactivated. Can assume the values
Web (as described in the first section of this post). Keep in mind that the elements you want to include in the feature might dictate what will be its scope.
Title (optional): Title of the Feature as shown in the Feature list.
Description (optional): Description of the Feature as shown in the Feature list, below the Feature title.
Version (optional): Version number of the Feature.
Creator (optional): Name of the author of the Feature.
SolutionId (optional): ID of the Solution that the Feature belongs to.
ImageUrl (optional): URL of the image that will be used as icon in the Feature list. If this attribute is not present, SharePoint will use the default Feature icon.
ImageUrlAltText (optional): Alternative text used in the Feature icon.
Hidden (optional): Specifies if the Feature should be hidden from the Features list. The default value is
ActivateOnDefault (optional): Specifies if the Feature should be automatically activated after it is installed. This attribute is only used if the Feature scope is
WebApplication, otherwise it is ignored. The default value is
AlwaysForceInstall (optional): Specifies if the Feature should always be installed, even if it's already installed. The default value is
AutoActivateInCentralAdmin (optional): Specifies if the Feature should automatically be activated in its scope. This attribute has no meaning for Features of scope
Farm. The default value is
RequireResources (optional): Specifies if SharePoint should look for a culture-specific resource file for this Feature. If there is no resource file for the current culture, the Feature is hidden in the Features list (but can still be activated by object model or console command). The default value is
DefaultResourceFile (optional): Defines the name of the resources files. By the default all resource files are named
XX-xx is the culture code), but setting this attribute with the value
MyResourceFile will cause SharePoint to look for filenames like
ReceiverAssembly (optional): Full qualified name of the assembly that contains the Custom Feature Event Receiver class. This attribute is always used with the
ReceiverClass (optional): Name of the class that implements the Custom Feature Event Receiver. This attribute is always used with the
<ActivationDependencies> element is optional and is used when you want to create a dependency between two Features. In other words, if a certain Feature A depends on some Element from a Feature B, creating an activation dependency in Feature A ensures that it won't be activated if Feature B is not activated first. This element can contain any number of
<ActivationDependency> elements whose only attribute (
FeatureId) is the ID of the Feature upon which this Feature is dependent.
<ElementManifests> element is also optional although it is used very often since it contains the list of Elements that belong to the Feature. This element can contain two types of child elements:
<ElementManifest> element, which points to a XML file that describes one or more SharePoint Feature Elements.
<ElementFile> element, which points to a generic file that is part of the Feature but is not an Element Manifest. An example of such a file can be a master page or a
Both elements have a
Location attribute that must contain the path to the referenced file. Most of the next posts in this series describe each type of Element Manifest.
<Properties> element is optional and it defines a property bag that can be accessed in Custom Feature Event Receivers. This element contains
<Property> elements which have two attributes:
Key: Name of the property key, in the property bag.
Value: Value of the property, in the property bag.
This property bag can be very useful to send parameters to a Custom Feature Event Receiver whose behavior can be parameterized.
Feature Installation and Uninstallation
Although the best way to install a Feature is through a Solution, you can do it manually. Just keep in mind that you must do it in all the servers of the farm (whereas with the Solution, the multi-server deployment is automatically assured).
To install a Feature you have to create a folder in
C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES with the name of the Feature and copy the
feature.xml and any other files (like Element Manifests) to that folder. Then you have to execute the following console command:
stsadm -o installfeature -name MyFolderName
MyFolderName is the name you gave the folder that contains the Feature.
To uninstall the Feature you have to execute the opposite console command (see below) and remove the folder you created.
stsadm -o uninstallfeature -name MyFolderName
Feature Activation and Deactivation
Similarly, besides activating and deactivating the Feature using the SharePoint UI, you can do it using console commands. To activate a Feature you have to execute the following command:
stsadm -o activatefeature -name MyFolderName -url http://MyServer/MyWebSite
MyFolderName is the name of the folder that contains the Feature, and
http://MyServer/MyWebSite is the URL address of the web site where you want to activate the Feature.
To deactivate it, you call the opposite command, as shown below:
stsadm -o deactivatefeature -name MyFolderName -url http://MyServer/MyWebSite