Skip navigation

Windows SharePoint Services 3.0

Introducing the Feature Framework

CoverStory

LANGUAGES: ALL

ASP.NET VERSIONS: 2.0

 

Windows SharePoint Services 3.0

Introducing the Feature Framework

 

By Vikram Srivatsa

 

Microsoft has released the RTM 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. Based on the final release of WSS 3.0, we ll discuss the Feature Framework with respect to MOSS 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. 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 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 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: Server:/_layouts/ManageFeatures.aspx.

 

To view the Features at the level of a specific site, use the following URL: Server:/SiteDirectory/SiteName/_layouts/ManageFeatures.aspx, substituting SiteName with the actual name of the site. A sample Site Features listing from a MOSS 2007 installation is shown 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 example 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 MOSS 2007 are provisioned as Features. For example, Office SharePoint Server Enterprise is a Feature that can be activated and deactivated. This Site Features example 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 installed at the Server Farm scope are in the Activated state by default.

Figure 3: Scoping options available for a Feature.

 

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 which 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.

 

Further, 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; 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).

 


Figure 4: Feature dependency.

 

Building Custom Site Features

To build custom site Features we must understand the Feature.xml file, which contains the core definitions for the Features. The basic structure of a Feature.xml file is illustrated in Figure 5. The elements that are part of the Feature.xml file are described in Figure 6.

 

   

   

   

   

   

   

Figure 5: The Feature.xml File.

 

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: Elements that are part of the Feature.xml file.

 

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

 

 Title="$Resources:spscore,PeopleFeatures_MySite_Text;"

 Description="$Resources:spscore,PeopleFeatures_MySite_Desc;"

 Version="12.0.0.0"

 Scope="Farm"

 Hidden="TRUE"

 xmlns="http://schemas.microsoft.com/sharepoint/"

 

     

 

Figure 7: The mysitefeatureelements.xml file.

 

We can see that ElementManifest points to a different location; this is a separate XML file, namely mysitefeatureelements.xml. ElementManifest 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, let s take a look at the Feature element definition for the MySite Feature, given in the mysitefeatureelements.xml (see Figure 8).

 

  "100" ControlSrc="~/_controltemplates/mysitelink.ascx"/>

 

  "100" ControlSrc="~/_controltemplates/mylinks.ascx"/>

 

   "100" ControlSrc="~/_controltemplates/

  mysiteredirection.ascx"

Figure 8: The Feature element definition for the MySite Feature.

 

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, then 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 must 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, as shown here:

 

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 a property of 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 must be added to the Features collection at the specific scope. To remove a Feature, it is necessary to remove the Feature from the Features 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);

   }

}

 

Please 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.

 

References

 

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

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish