Windows SharePoint Services 3.0

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 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. Based on the final release of WSS 3.0, we ll discuss theFeature Framework with respect to MOSS 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 scopeand activation capabilities. For example, consider a document library. Adocument library is a logical element provided out of the box with WSS. Fromthe perspective of the Feature Framework, a document library is a Feature thathas been activated in WSS and can be repeatedly used in multiple sites.

A document library is a basic element. 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 to theadministrator, who can activate or deactivate the Feature based on the specificscenario, thus providing 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 used it as part of their products. The Site Features can beaccessed from the MOSS 2007 installation at the top-level using the followingURL: Server:/_layouts/ManageFeatures.aspx.

To view the Features at the level of a specific site, usethe following URL: Server:/SiteDirectory/SiteName/_layouts/ManageFeatures.aspx,substituting SiteName with the actual name of the site. A sample Site Featureslisting 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 deactivatea Feature. The Site Features example shows the administrative UI for theFeatures installed on the SharePoint instance. We can see that the FeatureFramework has been leveraged by MOSS 2007 itself; some of the additionalcapabilities that ship as part of MOSS 2007 are provisioned as Features. Forexample, Office SharePoint Server Enterprise is a Feature that can be activatedand deactivated. This Site Features example 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 ProgramFilesCommon FilesMicrosoft Sharedweb server extensions12TEMPLATEFEATURESfolder. 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.

Figure 3: Scopingoptions available for a Feature.

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 which is dependent on another Feature that implements aspecific custom list, it would not be possible to activate the Workflow Featurewithout the custom list Feature.

Further, the dependency of a Feature can be combined withscope. 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; Feature 2 is defined at a lower scope (Site Level) and isdependent on Feature 1, which is defined at a higher scope (Site CollectionLevel).

Figure 4: Feature dependency.

Building Custom Site Features

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

                        Figure 5: TheFeature.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: Elementsthat are part of the Feature.xml file.   Let s now take a look at the Feature.xml file for thebuilt-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.xmlfile.   We can see that ElementManifest points to a differentlocation; this is a separate XML file, namely mysitefeatureelements.xml.ElementManifest 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, let s take a look at the Feature element definitionfor 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: TheFeature element definition for the MySite Feature.   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, then select theWSS12.xsd schema from the following folder: Program FilesCommonFilesMicrosoft Sharedweb server extensions12TEMPLATEXMLwss12.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 must be deployed into the Program FilesCommon FilesMicrosoftSharedweb server extensions12TEMPLATEFEATURES folder. The command-lineSTSADM tool is used to install and activate Features, as shown here:  STSADM -o installfeature -filename MyFeature/feature.xmlSTSADM -o activatefeature -filename MyFeature/feature.xml -url http://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 a property of the SPWeb, SPSite, and SPWebApplicationclasses. The mechanism to access the Features at various scopes is shown inFigure 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 must be added to theFeatures collection at the specific scope. To remove a Feature, it is necessaryto remove the Feature from the Features 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);    }}   Please refer to the WSS 3.0 SDK for more detailedinformation on understanding 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.  ReferencesWindows SharePoint Services 3.0: http://www.microsoft.com/downloads/details.aspx?FamilyID=d51730b5-48fc-4ca2-b454-8dc2caf93951&DisplayLang=enWindows SharePoint Services 3.0 SDK: http://www.microsoft.com/downloads/details.aspx?familyid=05E0DD12-8394-402B-8936-A07FE8AFAFFD&displaylang=enMicrosoft Office SharePoint Server 2007 Trial: http://www.microsoft.com/downloads/details.aspx?FamilyID=2e6e5a9c-ebf6-4f7f-8467-f4de6bd6b831&displaylang=enMicrosoft Office SharePoint Server 2007 SDK (includesWSS 3.0 SDK): http://www.microsoft.com/downloads/details.aspx?familyid=6d94e307-67d9-41ac-b2d6-0074d6286fa9&displaylang=en  Vikram Srivatsa isa Software Designer in the HP Services Advanced Technology Group atHewlett-Packard Company and is based out of Bangalore, India.