Basics of Features - Features are a part of Windows SharePoint Services (WSS) and are collections of logically related items and operations. These features can be used repeatedly across different site definitions and greatly reduce the complexity that is involved in the simple site customizations. Using Features reduces the issues that are related to the versioning and inconsistencies among different front-end web servers in a server farm and also eliminate the need to copy code blocks in case the need arises to change simple functionality.
The Feature framework provided by WSS can be used to extend the functionality and create customized solutions for the web application, site collections, sites and sub sites. This means that an Administrator can deploy the custom Features at the web application level, an individual site or also across the server farm.
Features provide the following capabilities:
- Provides a pluggable behavior to enable installing and uninstalling the features within an existing deployment
- Provides capabilities for activation or deactivation within a scope
- Reduces the issues that are related to the versioning and inconsistencies among different front-end web servers
- Provides a framework to easily deploy SharePoint solutions in a distributed environment
How to Implement Features – The Windows SharePoint Services provides a number of out-of-box features, which are stored in the following directory:
Each of the folders within the Features directory represents an individual Feature, which includes a Features.xml file defining the base properties of the Feature and also lists the elements that are bound to it. This includes XML files, other supporting files, etc. An individual Feature might comprise of just a Feature.xml file or can contain any number of supporting files such as - .aspx, .xsn, htm, .dll, resx (resource file), etc.
To implement a custom Feature, you also need to create a subdirectory within the Features directory mentioned above. After the custom Feature directory has been created with all the supporting files, the Feature can be installed and activated. There are three ways to do it namely – the command line operations using stsadm.exe, the WSS user interface or the WSS object model. When you install a Feature, the definition is available throughout the server farm, whereas when you activate the Feature, it becomes available for custom functionality within the scope in which it has been activated.
Components of Features – Since the Feature.xml file defines the base properties of the Feature, this becomes a mandatory file to be created as a part of the creating a Feature. Apart from this, the Feature might also include any number of supporting files that describes the elements of the Feature. The Feature element is the root element of the Feature.xml file that defines the Feature and also specifies the location of the dependencies, files, assemblies, or properties that comprise the functionality of the Feature.
The ElementManifests element within the Feature element, points to one or more XML files, whose top level Elements tag contain the definition of the elements that support the functionality of the Feature.
The Element Manifest in Detail - An element manifest is another XML file which may be used within a Feature to define the elements which will be created and deployed. There is a huge amount dependency, which can be deployed using an element manifest. A sample element manifest to deploy an instance of a list would look something like this:
Once you have created an Element Manifest then you need to register this in your Feature definition so that SharePoint is aware of the file when the Feature is activated after it’s installation. Assuming that your elements file is called LocationPart.xml then your feature definition would now look something like the one below that specifies the installation dependencies, special fields, and relative paths to the element definition files:
The Element Manifest in Detail - An element manifest is another XML file which may be used within a Feature to define the elements which will be created and deployed. There is a huge amount dependency, which can be deployed using an element manifest. A sample element manifest to deploy an instance of a list would look something like this:
Once you have created an Element Manifest then you need to register this in your Feature definition so that SharePoint is aware of the file when the Feature is activated after it’s installation. Assuming that your elements file is called LocationPart.xml then your feature definition would now look something like the one below that specifies the installation dependencies, special fields, and relative paths to the element definition files:
Scope of Custom Features – As previously explained, the scope of a custom Feature can vary depending upon the requirements to the site level, site collection level, web application level, or the server farm level. This is to be kept in mind that the Feature can be scoped only at a single level, i.e., it can only have a single scope defined by the Scope attribute inside the Feature element within Feature.xml file. The three types of scopes are as under:
- Server Farm: A Feature that has a scope of a Server Farm is by default always activated. A farm scoped Feature might contain links to the _layout pages and files, _admin pages, etc.
- Web Application: A web application scoped feature might contain elements that reference the assemblies of the virtual server and/or the one’s that reference the administrative links.
- Site Collection/Site: A Feature that is scoped at the site collection level applies to the site collection containing a top level site and the sub-sites within the top level site (including Web Parts, etc.). A site scoped Feature on the other hand is only for the individual site for which it is activated. A Feature scoped at the site or site collection level includes list definitions, modules, content types, etc.
Dependencies for Features – Features can be defined such that they can be dependent on other Features for their activation, but they have to follow the scope. A feature can be dependent on another Feature of the same scope or could also have a cross-scope dependency, which means that a Feature of a particular scope can have a dependency on a Feature of a different scope. There are some restrictions though that needs to be kept in mind while defining dependencies. To be clearer on this, let us take an example – A Feature defined at the scope of the site level can be dependent on a Feature defined at the scope of site collections level, but since the Feature defined at the scope of the site collection level has more restrictive scope, it cannot be dependent on a Feature scoped at the site level.
The Windows SharePoint Service Object Model - For the purpose of determining the existence of Feature in a particular scope or for the purpose of knowing whether the installed features are activated or deactivated at a particular scope, the WSS provides an object model that can be used for the same. There are many Feature classes within the Windows SharePoint Services object model. They are as follows:
- SPFeature: This class helps in determining the presence of the Feature in a particular scope. If the instance of the Feature is returned, it means that the Feature for that scope is activated, else it is considered that the object is not added
- SPFeatureProperty: This class represents a single property of a particular Feature
- SPFeatureScope: This class provides an enumeration of all the possible scopes that can be defined for a particular Feature
- SPFeatureDefinition: This class can be used for determining and defining the basic properties of a Feature
- SPElementDefinition: This class determines the Element that is to be used when a Feature is activated or used.
Below is a very small example that showcases the use of a few of these cases in determining the list of names and the GUID's of the Features that are activated for a particular site.
Creating Custom Features – We will now look at some real world scenario by creating a custom list using Features. We will also see as to how we can install and activate the Feature using the command line STSADM.exe commands. This Feature will be designed to create a List instance and add some initial data to it.
and now we will create a Timesheet.xml file that will be used to show the List properties and also populate the custome list with some data.
One important thing that we still need to do is to create the core Feature.xml file. So let's get started and create the Feature.xml file, which is the first file that is used after the Feature is activated, for it's functionality. Below is the screen shot of the Feature.xml file:
After all the files are created, we will now use the command line STSADM.exe commands to install and activate the Feature. Open the command prompt and run the following command to install and activate Feature:
<installation drive>\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin\stsadm -o installfeature -filename LitwareTimesheets/Feature.xml -force
IISReset<installation drive>\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\bin\stsadm -o activatefeature -filename LitwareTimesheets/Feature.xml -url http://localhost -force
But before the Feature is installed and activated, it is required to copy the files in the designated folder within the Features directory as explained in the earlier part of this tutorial. For the same use the following command:
xcopy /e /y Features\LitwareTimeSheets\* <installation drive>\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Features\LitwareTimeSheets\
Now you can go to the default website and see that the Feature has been installed and activated by the name of TimeSheets.
--------------------------------------------------------------------------------------------------------------
This article contains examples from the book "7 Development Projects For Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0"
