asp:Feature

 

WSS and MOSS

Introducing the Feature Framework with Windows SharePoint Services 3.0 and MOSS 2007

 

By Vikram Srivatsa

 

Microsoft has released the Beta 2 version of Windows SharePoint Services (WSS) 3.0. This new version is based on ASP.NET 2.0 and forms the core building block on which Microsoft Office SharePoint Server (MOSS) 2007 is built.

 

This article explores a new feature of WSS 3.0 known as the Feature Framework. We ll also discusses the Feature Framework with respect to MOSS 2007. This article is based on Beta 2 of WSS 3.0; as with any Beta technology, there could be changes before the final version of the product is released. Currently, the final release is scheduled for January 2007.

 

The Feature Framework

A Feature can be described as a logical element or the grouping of a set of logical elements with a common goal and having a scope and activation capabilities. For example, consider a document library. A document library is a logical element, provided out of the box with WSS. From the perspective of the Feature Framework, a document library is a Feature that has been activated in WSS and can be repeatedly used in multiple sites.

 

A document library is a basic element, and the Feature Framework goes beyond this. It allows designers to define and group several logical elements together and package them as a Feature that can be activated and made available to the users. The set of logical elements bundled together as a Feature acts as a specific piece of functionality and addresses a common end-user scenario.

 

To illustrate this, consider a custom solution built as part of a specific requirement, such as a customized document library for storing project requirements that has certain custom menus and a specific document library event handler. The Feature Framework allows us to package this custom solution as a Feature and use it repeatedly in multiple sites.

 

A Feature also supports scoping and provides control to the administrator, who can activate or deactivate the Feature based on the specific scenario, thus providing a control over its provisioning. Having gained a basic understanding of the concept of the Feature Framework, let s now explore how the Feature Framework is used by Microsoft as part of WSS 3.0 and MOSS 2007.

 

Built-in Site Features in WSS and MOSS 2007

A good starting point to understand a new technology or a concept introduced by Microsoft is to explore the ways in which Microsoft designers have themselves used it as part of their products.

 

The Site Features can be accessed from the MOSS 2007 installation at the top level using the following URL: http://Server:<Port>/_layouts/ManageFeatures.aspx.

 

To view the Features at the level of a specific site, use the following URL: http:// Server:<Port>/SiteDirectory/SiteName/_layouts/ManageFeatures.aspx, substituting SiteName with the actual name of the site.

 

A sample Site Feature listing from a MOSS 2007 installation is illustrated in Figure 1.

 

Figure 1: Site Features in MOSS 2007.

 

As shown in Figure 1, it is possible to activate and deactivate a Feature. The Site Features listing above shows the administrative UI for the Features installed on the SharePoint instance.

 

We can see that the Feature Framework has been leveraged by MOSS 2007 itself; some of the additional capabilities that ship as part of the MOSS 2007 Product are provisioned as Features. For example, Office SharePoint Server Enterprise is a Feature that can be activated and deactivated. This Site Features listing includes the Enterprise features of MOSS 2007, such as Business Data Catalog, Forms Services, and Excel services. The pluggable nature of the Features makes the deployment of specific pieces of functionality easy and robust.

 

The Feature Framework can also be leveraged to modify and customize the standard user interface provided by WSS 3.0. It is possible to define a new menu or add a new action to a menu using Features.

 

The Features are physically stored in the \Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES folder. Each Feature is installed as a separate sub folder. Figure 2 shows the Features of a sample MOSS 2007 installation.

 

Figure 2: The Features folder.

 

The Scope of a Feature

A Feature can have a scope associated with it, which can be defined at the level of a site or a site collection, a Web application, or a server farm. The different scoping options available for a Feature are shown in Figure 3.

 

Scope	Description
Site	The Feature is defined at site level.
Site Collection	The Feature is defined at the level of a site collection.
Web Application	The Feature is defined at the level of a Web application or a virtual server.
Server Farm	The Feature is defined at the level of a server farm. All Features that are installed at the Server Farm scope are in the activated state by default.

Figure 3: Feature scopes.

 

Feature Dependencies

Features also support the concept of dependencies. A Feature can be defined to be dependent on one or more other Features. This implies that the top-level Feature would require all the dependencies to be present before it can be activated.

 

For example, if we have a top-level Feature that implements a workflow and this is dependent on another Feature that implements a specific custom list, it would not be possible to activate the Workflow Feature without the custom list Feature.

 

Furthermore, the dependency of a Feature can be combined with scope. A dependency that spans multiple scopes is termed as a cross-scope dependency. A Feature at the site level can be dependent on a Feature at the site collection level. However, the opposite is not true, i.e., a Feature at the level of a site collection cannot be made dependent on a Feature at the site level.

 

A Feature at a lower scope can be defined to be dependent on a Feature at a higher scope. Figure 4 illustrates a cross-scope dependency between two Features.

 

Figure 4: Feature dependency.

 

Here, Feature 2 is defined at a lower scope (Site Level) and is dependent on Feature 1, which is defined at a higher scope (Site Collection Level).

 

Building Custom Site Features

To build custom site Features we need to understand the Feature.xml file; this contains the core definitions for the Features. The basic structure of a Feature.XML file is illustrated in Figure 5.

 

Figure 5: The Feature.xml file.

 

The elements that are part of the Feature.xml file are described in Figure 6.

 

Element	Description
Feature	This element holds the Title, Id, Scope, etc. of the Feature.
ActivationDependencies	This element is used to specify any dependencies on other Features.
ElementManifests	This defines the Feature element.
Properties	This element acts as a property bag for the Feature and can be used to store name-value pairs of data related to the Feature.

Figure 6: Feature.xml elements.

 

Let s now take a look at the Feature.xml file for the built-in MySite Feature. This is illustrated in Figure 7.

 

Figure 7: The MySite Feature.xml file.

 

We can see that ElementManifests points to a different location this is a separate XML file, namely the mysitefeatureelements.xml . ElementManifests is usually used as a link to a separate XML file where the Feature element is actually defined.

 

Some of the common definitions of Feature elements include things like custom actions, controls, workflows, and receivers. The element definition can include either one element or a combination of elements. The custom action element can be used to modify the UI provided by WSS 3.0 and to add new menu items, etc. The Workflow element can be used for associating a workflow as a Feature. The receiver element is used for associating an assembly containing custom code that defines an event handler. The control element is used to define a control that needs to be implemented.

 

Next we take a look at the Feature element definition for the MySite Feature, given in the MySiteFeatureElements.xml (see Figure 8).

 

Figure 8: MySiteFeatureElements.xml.

 

We can see that the MySiteFeatureElements.xml file is comprised of control definitions with pointers to the actual .ASCX (User Control) files that implement the control.

 

A useful tip for building these Feature XML files is to use VS 2005. VS 2005 comes with an XML Editor that provides IntelliSense for XML based on a schema. To leverage this feature, add a new XML file in Visual Studio and select the Properties window for the XML. In the Properties window, select the Schemas property, as shown in Figure 9.

 

Figure 9: Select the Schemas property in the Properties window.

 

In the browse dialog box, choose Add and select the WSS12.xsd schema from the following folder: \Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\XML\wss12.xsd. Once the schema has been set, the XML Editor within VS 2005 provides validation and IntelliSense for writing XML, as shown in Figure 10.

 

Figure 10: XML IntelliSense in VS 2005.

 

Once the Feature definition is complete, the complete folder needs to be deployed into the \Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURES folder. The command-line STSADM tool is used to install and activate Features:

 

STSADM -o installfeature -filename MyFeature/feature.xml

STSADM -o activatefeature -filename MyFeature/feature.xml -url http://localhost

 

Accessing Features Using the Object Model

The SPFeature class represents a Feature. Features can be accessed from the Object Model using different objects based on the scope. The Features Collection is found as a property on the SPWeb, SPSite, and SPWebApplication classes. The mechanism to access the Features at various scopes is shown in Figure 11.

 

Figure 11: Retrieving Features using the Object Model.

 

At the SPFarm level, all the Features installed are always activated. The Features collection contains only the activated Features.

 

To activate a Feature, a Feature needs to be added to the Features collection at the specific scope. To remove a Feature it is necessary to remove the Feature from the Feature collection. The addition and removal of the Feature is done based on the Feature Id, which is a Guid. A sample code snippet for removing a Feature based on its name is shown here:

 

foreach (SPFeature objFeature in objSite.Features)

{

   if (objFeature.Definition.DisplayName == "MyFeature"){

        objSite.Features.Remove(objFeature.Definition.Id);

   }

}

 

Refer to the WSS 3.0 SDK for more detailed information on understanding and manipulating Features using code.

 

Conclusion

This article introduces the Feature Framework (which is part of WSS 3.0) and discusses concepts related to the framework, such as dependencies, activation, and scope. The article also discusses how to use the Feature Framework via an object model. Look for an updated article in asp.netPRO after the final version ships.

 

References

Office 2007 Preview Site

Download Office System 2007 Beta 2

 

Vikram Srivatsa is a Software Designer in the HP Services Advanced Technology Group at Hewlett-Packard Company and is based out of Bangalore, India.