asp:Feature
WSS and MOSS
Introducing the Feature Framework with WindowsSharePoint Services 3.0 and MOSS 2007
By Vikram Srivatsa
Microsoft has released the Beta 2 version of WindowsSharePoint Services (WSS) 3.0. This new version is based on ASP.NET 2.0 andforms 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 asthe Feature Framework. We?ll also discusses theFeature Framework with respect to MOSS 2007. This article is based on Beta 2 ofWSS 3.0; as with any Beta technology, there could be changes before the finalversion of the product is released. Currently, the final release is scheduledfor January 2007.
The Feature Framework
A Feature can be described as a logical element or thegrouping of a set of logical elements with a common goal and having a scope andactivation capabilities. For example, consider a document library. A documentlibrary is a logical element, provided out of the box with WSS. From theperspective of the Feature Framework, a document library is a Feature that hasbeen activated in WSS and can be repeatedly used in multiple sites.
A document library is a basic element, and the FeatureFramework goes beyond this. It allows designers to define and group severallogical elements together and package them as a Feature that can be activatedand made available to the users. The set of logical elements bundled togetheras a Feature acts as a specific piece of functionality and addresses a commonend-user scenario.
To illustrate this, consider a custom solution built aspart of a specific requirement, such as a customized document library forstoring project requirements that has certain custom menus and a specificdocument library event handler. The Feature Framework allows us to package thiscustom solution as a Feature and use it repeatedly in multiple sites.
A Feature also supports scoping and provides control tothe administrator, who can activate or deactivate the Feature based on the specificscenario, thus providing a control over its provisioning. Having gained a basicunderstanding of the concept of the Feature Framework, let?s now explore howthe 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 aconcept introduced by Microsoft is to explore the ways in which Microsoftdesigners have themselves used it as part of their products.
The Site Features can be accessed from the MOSS 2007installation 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, usethe 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 2007installation is illustrated in Figure 1.
Figure 1: Site Features in MOSS 2007.
As shown in Figure 1, it is possible to activate and deactivatea Feature. The Site Features listing above shows the administrative UI for theFeatures installed on the SharePoint instance.
We can see that the Feature Framework has been leveragedby MOSS 2007 itself; some of the additional capabilities that ship as part ofthe MOSS 2007 Product are provisioned as Features. For example, ?OfficeSharePoint Server Enterprise? is a Feature that can be activated anddeactivated. This Site Features listing includes the Enterprisefeatures of MOSS 2007, such as Business Data Catalog, Forms Services, and Excelservices. The pluggable nature of the Features makes the deployment of specificpieces of functionality easy and robust.
The Feature Framework can also be leveraged to modify andcustomize the standard user interface provided by WSS 3.0. It is possible todefine a new menu or add a new action to a menu using Features.
The Features are physically stored in the \ProgramFiles\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\FEATURESfolder. Each Feature is installed as a separate sub folder. Figure 2 shows theFeatures 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 canbe defined at the level of a site or a site collection, a Web application, or aserver farm. The different scoping options available for a Feature are shown inFigure 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. AFeature can be defined to be dependent on one or more other Features. Thisimplies that the top-level Feature would require all the dependencies to bepresent before it can be activated.
For example, if we have a top-level Feature thatimplements a workflow and this is dependent on another Feature that implementsa specific custom list, it would not be possible to activate the WorkflowFeature without the custom list Feature.
Furthermore, the dependency of a Feature can be combinedwith scope. A dependency that spans multiple scopes is termed as a cross-scopedependency. A Feature at the site level can be dependent on a Feature at thesite collection level. However, the opposite is not true, i.e., a Feature atthe level of a site collection cannot be made dependent on a Feature at thesite level.
A Feature at a lower scope can be defined to be dependenton a Feature at a higher scope. Figure 4 illustrates a cross-scope dependencybetween two Features.
Figure 4: Feature dependency.
Here, Feature 2 is defined at a lower scope (Site Level) andis dependent on Feature 1, which is defined at a higher scope (Site CollectionLevel).
Building Custom Site Features
To build custom site Features we need to understand theFeature.xml file; this contains the core definitions for the Features. Thebasic 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 aredescribed 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 thebuilt-in MySite Feature. This is illustrated in Figure 7.
Figure 7: The MySite Feature.xml file.
We can see that ElementManifests points to a differentlocation ? this is a separate XML file, namely the ?mysitefeatureelements.xml?.ElementManifests is usually used as a link to a separate XML file where theFeature element is actually defined.
Some of the common definitions of Feature elements includethings like custom actions, controls, workflows, and receivers. The elementdefinition can include either one element or a combination of elements. Thecustom action element can be used to modify the UI provided by WSS 3.0 and toadd new menu items, etc. The Workflow element can be used for associating aworkflow as a Feature. The receiver element is used for associating an assemblycontaining custom code that defines an event handler. The control element isused to define a control that needs to be implemented.
Next we take a look at the Feature element definition for theMySite Feature, given in the MySiteFeatureElements.xml? (see Figure 8).
Figure 8: MySiteFeatureElements.xml.
We can see that the MySiteFeatureElements.xml file is comprisedof control definitions with pointers to the actual .ASCX (User Control) filesthat implement the control.
A useful tip for building these Feature XML files is touse VS 2005. VS 2005 comes with an XML Editor that provides IntelliSense forXML based on a schema. To leverage this feature, add a new XML file in VisualStudio 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 Schemasproperty in the Properties window.
In the browse dialog box, choose Add and select theWSS12.xsd schema from the following folder: \Program Files\CommonFiles\Microsoft Shared\web server extensions\12\TEMPLATE\XML\wss12.xsd. Oncethe schema has been set, the XML Editor within VS 2005 provides validation and IntelliSensefor writing XML, as shown in Figure 10.
Figure 10: XML IntelliSense in VS 2005.
Once the Feature definition is complete, the completefolder needs to be deployed into the \Program Files\Common Files\MicrosoftShared\web server extensions\12\TEMPLATE\FEATURES folder. The command-lineSTSADM tool is used to install and activate Features:
STSADM -o installfeature -filename MyFeature/feature.xml
STSADM -o activatefeature -filename MyFeature/feature.xml -urlhttp://localhost
Accessing Features Using the Object Model
The SPFeature class represents a Feature. Features can beaccessed from the Object Model using different objects based on the scope. TheFeatures Collection is found as a property on the SPWeb, SPSite, andSPWebApplication classes. The mechanism to access the Features at variousscopes is shown in Figure 11.
Figure 11: Retrieving Features usingthe Object Model.
At the SPFarm level, all the Features installed are alwaysactivated. The Features collection contains only the activated Features.
To activate a Feature, a Feature needs to be added to theFeatures collection at the specific scope. To remove a Feature it is necessaryto remove the Feature from the Feature collection. The addition and removal ofthe Feature is done based on the Feature Id, which is a Guid. A sample codesnippet 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 onunderstanding and manipulating Features using code.
Conclusion
This article introduces the Feature Framework (which ispart of WSS 3.0) and discusses concepts related to the framework, such asdependencies, activation, and scope. The article also discusses how to use theFeature Framework via an object model. Look for an updated article in asp.netPRO after the final versionships.
References
Office2007 Preview Site
Download Office System 2007 Beta 2
VikramSrivatsa is a Software Designer in the HP Services Advanced TechnologyGroup at Hewlett-Packard Company and is based out of Bangalore, India.