Application Deployment Through Features

Features are the preferred packaging mechanism for SharePoint components. We have used features for deploying sample code throughout this book for the simple reason that they are easy to activate within existing sites and also have object and event models that are very powerful. A feature can be activated with a WSS site in five ways: through the Site Settings Web pages, the STSADM command line, site definition references, feature activation dependencies, or feature stapling. Because we have already looked at the first three options, we will now look at using feature activation dependencies and feature stapling.

Feature Activation Dependencies

Features can include activation dependencies. When WSS activates a feature that defines activation dependencies, it automatically activates any dependent feature that has already been activated. The TeamCollab feature that ships as a built-in feature with WSS provides a good example. The TeamCollab feature in and of itself provides no implementation. However, it defines activation dependencies on 19 other built-in features that define the collaboration lists and libraries in the Team Site.

Activating the TeamCollab feature forces the activation of these 19 other features that make all of the collaboration list types available such as Announcements, Contacts, Tasks, Events, and Document Libraries. As you can see, feature activation dependencies can be used to aggregate many features together into a common feature set that can then be activated and deactivated through a single high-level feature. Note that the STS site definition contains a Web feature reference to the TeamCollab feature so that all collaboration features are available within any new Team Site, Blank Site, or Document Workspace.

To demonstrate the use of feature dependencies, let’s revisit the LitwareTypes feature from Chapter 6, “Lists and Content Types.” We begin with a simple refactoring of the feature, in which we remove the list data from the feature in the VendorList.xml file. First, create a new feature called VendorListInstance within the same Visual Studio project. To do this, we create a folder called VendorListInstance within the Features folder and add a Feature.xml file with the following content:

 <?xml version="1.0" encoding="utf-8"?> <Feature   Id=""   Title=" Chapter 8: Vendor List Instance"   Description="Demo from Inside Windows SharePoint Services"   Version="1.0.0.0"   Hidden="false"   Scope="Web"   xmlns="http://schemas.microsoft.com/sharepoint/">   <ActivationDependencies>     <!-- LitwareTypes Feature -->     <ActivationDependency        FeatureId=""/>   </ActivationDependencies>   <ElementManifests>     <ElementManifest Location="VendorListInstance.xml" />   </ElementManifests> </Feature>

We create an ActivationDependencies node within the feature to define elements that will be enabled when this feature is added. Next, we move the ListInstance node from the VendorList.xml file to a new VendorListInstance.xml file within the VendorListInstance feature folder. VendorListInstance.xml should look like the following code:

 <Elements xmlns="http://schemas.microsoft.com/sharepoint/">   <ListInstance TemplateType="10001"                  Title="Vendors" Url="Vendors"                 Description="Litware Vendors"                 OnQuickLaunch="True" >     <Data>       <Rows>         <Row>           <Field Name="Title">Acme Corp, Inc</Field>           <Field Name="FullName">Bob Jones</Field>           <Field Name="WorkPhone">[phone]</Field>           <Field Name="Industry">High Tech</Field>           <Field Name="CompanySize">101-1000</Field>           <Field Name="ActivityNotes">They got the best widgets</Field>         </Row>         <!-- (Additional rows omitted for clarity) -->       </Rows>     </Data>   </ListInstance> </Elements>

We have created a feature that provisions a new list instance on activation. However, the feature is designed to force the activation of the dependent feature that defines the underlying list type when this is necessary.

Feature Stapling

A feature can also be used to attach one or more other features to a site definition through a technique known as feature stapling. For example, instead of creating a custom site definition, you can elect to create a custom feature to extend one of the built-in WSS site templates, such as Team Site or Blank Site, by automatically associating it with the Litware Types feature. You can extend a site template in this fashion by using a feature site template association.

To add the Litware Types feature to Team Site and Blank Site, you can simply create a new feature that associates the Litware Types feature with the site definition configurations identified by STS#0 and STS#1. The node that defines this relationship is the FeatureSiteTemplateAssociation node, in which the TemplateName parameter defines the site definition and configuration, and the Id parameter defines the feature that is added as part of the site definition. The Id parameter specifies the GUID of the feature to associate.

To use feature stapling, create a new feature to be used to associate one or more other features with one or more site templates. In the code samples for this chapter, we defined the new Feature folder named LitwareTypesDeploymentFeature in the Litware Types project in use since Chapter 6. This feature will only contain two files, the feature.xml file and the elements.xml file. Within the Elements node of Elements.xml, we created a FeatureSiteTemplateAssociation node for every site template to which we want to staple our feature. In this case, we want to staple the Litware Types feature to the Team Site (STS#0) and Blank Site (STS#1).

 <Elements xmlns="http://schemas.microsoft.com/sharepoint/">   <FeatureSiteTemplateAssociation     Id=""     TemplateName="STS#0" />   <FeatureSiteTemplateAssociation     Id=""     TemplateName="STS#1" /> </Elements>

A feature created to perform feature stapling can be defined to be activated at any of the four supported activation scopes, including the scopes of site, site collection, Web application, and farm. For example, if you define a stapling feature at Web application scope, it provides a quick and easy way to activate the features being stapled within every Team Site and Blank Site in the target Web application. In the sample code for this chapter, we designed the stapling feature at farm scope. Once this feature is activated, it makes the Litware Types feature active within every Team Site and Blank Site in the farm.

Going one step further, we could associate the Litware Types feature with Global site definition configurations, which makes it available to all sites as opposed to only sites created from a specific configuration. The following elements manifest would associate the feature with the Global site definition configuration:

 <Elements xmlns="http://schemas.microsoft.com/sharepoint/">   <FeatureSiteTemplateAssociation     Id=""     TemplateName="GLOBAL#0" /> </Elements>

Attaching the Litware Types feature to the Global site definition configuration makes it globally active in all sites throughout the current WSS farm, including the Central Administration sites. This technique is powerful because it provides an approach to using feature stapling to make custom list types available to every site within a farm. You can also use it to import Web Part description files into the Web Part gallery of every site collection on a farm-wide basis.

Keep in mind that feature stapling can also be used to associate features that contain event handlers. For example, imagine that you want to run a piece of custom code anytime a new site is created on a farm-wide basis. You can start by creating a site-scoped feature with a FeatureActivated event handler. Then you simply need to create a second farm-scoped feature to staple the first feature containing the event handler to the Global site definition configuration.