Microsoft SharePoint 2007 Technologies

482 16.4 Feature Receivers

tureC can depend upon FeatureA, and FeatureB can depend on Fea-

tureA.

n Multilevel dependencies are supported for Features that have the

Hidden attribute set to TRUE. For example, suppose you have three

Features, FeatureA, FeatureB, and FeatureC; FeatureB and FeatureC

have their

Hidden attribute set to FALSE, and FeatureA has its Hid-

den

attribute set to TRUE. In this scenario, you can have FeatureC depend

upon FeatureB, which in turn depends upon FeatureA.

When designing your Feature architecture, especially where cross-scope

activation dependencies are concerned, it is important to ensure that your

Feature is protected from being left in an undesirable state. For example, if

you have a collection of same-scoped Feature activation dependencies and

overlapping cross-scoped Feature activation dependencies, then you need to

make sure that in no circumstance is a Feature left activated when the Feature

upon which it depends has been deactivated. If this scenario is unavoidable,

then at the very least, you should ensure that your Feature can handle the

missing Feature gracefully.

16.4 Feature Receivers

A Feature receiver is a special type of event receiver assembly that allows you

to run custom code when specific Feature events occur, such as when a Fea-

ture is installed, activated, deactivated, or uninstalled. Figure 16.10 shows the

Feature.xml for the ApplyCorporateBrand Feature. In this particular example,

we use a Feature receiver to help push down a specific master page to all sites

within the site collection in which the Feature receiver is activated. This func-

tionality mimics the behavior of the “Reset all subsites to inherit this site/sys-

tem master page” setting on the Site Master Page Settings aspx page. When

the Feature is deactivated, we then reverse the process and set the master page

to the default Microsoft master page. The

Feature element has two attributes

specific to Feature receivers:

ReceiverAssembly and ReceiverClass. The

ReceiverAssembly attribute is set to the strong name of the assembly that

you would like to handle the events triggered by the Feature; the assembly

DLL must be installed in the global assembly cache. The

ReceiverClass

attribute is used in conjunction with the ReceiverAssembly attribute and

specifies the class within the receiver assembly that contains the event handler

code. In our example, the

ReceiverAssembly attribute is set to the MyMas-

terFeature receiver assembly and the

ReceiverClass attribute is set to the

MyMasterFeature.ChangeMaster receiver class. In addition to the receiver set-

tings, the ApplyCorporateBrand Feature definition file contains two

Prop-

erty

definitions, activateMaster and deactivateMaster; each property

value is set to the URL of a specific master page in the default master page gal-