Microsoft SharePoint 2007 Technologies

16.5 Feature Lifecycle 483

Chapter 16

lery. As previously mentioned, the properties defined in the Feature.xml file

are accessible to Feature receivers. Figure 16.11 shows some very basic code

for the ChangeMaster class in the MyMasterFeature receiver assembly. Once

again, it is important to note that this code is for demonstration purposes

only, as the code does not contain the appropriate exception handling

required for production. The ChangeMaster class inherits from the

SPFea-

tureReceiver

class, thus making it a Feature receiver class (line 9). Once you

have set up the Feature receiver inheritance, you are free to override the Fea-

ture receiver methods such as

FeatureInstalling, FeatureActivated,

FeatureDeactivating, and FeatureUninstalling. In this example, we

override the

FeatureActivated method (lines 11 thru 24) and the Feature-

Deactivating

method (lines 26 thru 39). The FeatureActivated method

retrieves the value associated with the

activateMaster property in the Fea-

ture definition, traverses through each site in the site collection, and sets the

site’s

MasterUrl and CustomMasterUrl properties equal to the value

retrieved from the activateMaster property. The

FeatureDeactivating

method retrieves the value associated with the deactivateMaster property in

the Feature definition, traverses through each site in the site collection, and

sets the site’s

MasterUrl and CustomMasterUrl properties equal to the value

retrieved from the

deactivateMaster property. The properties provided by

the

SPFeatureProperties object include a pointer to the parent of the Fea-

ture, so you always have access to the Web site, site collection, Web applica-

tion, or farm in which the Feature is being activated (line 16 and line 31).

16.5 Feature Lifecycle

So far we have discussed the various files, attributes, and elements that com-

prise the Feature architecture, but we have not really discussed how to actu-

ally create, install and activate a Feature. The basic lifecycle of a Feature

involves creating the Feature, deploying the Feature, installing the Feature,

activating the Feature, deactivating the Feature, uninstalling the Feature and

then ultimately removing the Feature files from all the front-end Web servers

(Figure 16.12). The adding and removing of Feature files can be performed

manually on each front-end Web server; however the best practice recom-

mendation is to use the Solution Deployment Framework to deploy and

manage the Feature. Using the Solution Deployment Framework offers the

advantage of being able to easily retract the solution from all Web servers

within the farm. Figure 16.12 doesn’t take into account the removal of the

files provisioned by the Feature itself. As a best practice, your Feature should

clean up its footprint during the uninstall process; in the event that the files

cannot be removed, such as is the case for master pages, the uninstall process

should ensure that the files are hidden or, at the very least, that all settings

revert to their default or prior settings. In the remainder of this section, we’ll

assume that the deployment and removal of the files, including provisioned

484 16.5 Feature Lifecycle

files, are handled, and we will focus on the creation, installation, activation,

deactivation, and uninstall phases of the life cycle.

16.5.1 Creating a Feature

As previously mentioned, a Feature is a folder containing one or more files that

define and deliver the functionality. There is no real rocket science behind the

creation of Features; the process involves creating a folder in the \Feature direc-

tory, creating a Feature definition file, and creating the additional files required

by the Feature, such as an element manifest file. Obviously, if your Feature reg-

isters an event receiver or implements a Feature assembly, then the process is

more complex and involves the development effort of creating the custom

Figure 16.11

MyMasterFeature.

ChangeMaster

Feature receiver

code (C#).