Feature Stapling & ActivationDependency Element (Feature)

Feature Stapling allows you to create a feature and then associate it with any site definition without ever touching the site definition files themselves. Your feature will be executed when the site is being provisioned. Feature Stapling is achieved through the creation of another feature that defines the association of your regular Feature and the site definition you want to “staple” it too. In other words, you need to create two Features to achieve a complete Feature Stapling implementation. Lifecycle of Stapling Feature   As per the above figure, step 3 & 4 is your stapling feature trying to modify elements from the site definition (i.e. out of the box lists / list view web parts and Step 6 is when the actual lists from the site definition are getting created. Feature Stapling  is the great way if the site definition is already in use (and sites have been created). Feature Stapling has two features. A "Stapler" feature which staples another feature to the site definition and the"Staplee" feature which will be stapled. For Example suppose you want to apply a custom Theme to all of the "Publishing site" site definitions. This can be solved by creating a feature which will apply the Custom theme to the site and it can be associated with the publishing site's site definition. Or Suppose if you want to activate a custom list to all the Team sites , this can also be solved creating a feature which on activating when you create a team site the custom list gets created. How to Create Feature stapler.

1. First we need to create the Features (Staplee) which we want install on creation of site (publishing or team site etc.). How to create feature.
2. Create a Feature Stapler as below <?xml version="1.0" encoding="utf-8" ?>

<Feature xmlns="http://schemas.microsoft.com/sharepoint/" Id="C384D136-79A8-48BD-AF73-C630547F4D8E" Title="ExampleStapler" Description="This feature staples the             other feature to the Team Site definition." Scope="Farm" Hidden="False"Version="1.0.0.0" />  

3. Create an element xml which is nothing but where feature association takes place.In order to add element.xml we need to create a module in Visual studio 2010 and then add the element.xml

<?xml version="1.0" encoding="utf-8" ?> <Elements xmlns="http://schemas.microsoft.com/sharepoint/"> <FeatureSiteTemplateAssociation Id="b8f334a0-1ffe-420d-b6e2-54a9faa6ba95"TemplateName="STS#0" /> <FeatureSiteTemplateAssociation Id="07cb8bd4-7004-4021-8355-48d17de287e5"TemplateName="STS#0" /> <FeatureSiteTemplateAssociation Id="90C924A7-32F7-4C19-BD4C-AF49EF0563A9"TemplateName="STS#0" /> </Elements> The FeatureSiteTemplateAssociationID element maps feature(The Features which we want to install on creation of Site) GUIDs to site definitions. Feature-stapling won't affect any sites which have already been created from a site definition, only subsequent sites. The only way to do this is to activate your features individually on the site. So Once you deploy Feature Stapler to web application level and then you create a team Site the associated (Stappled)  features will get activated.  

Feature Activation Dependencies used in SharePoint Features

Feature Activation Dependency allows to make Features dependent on each other. So if FeatureB has activation dependency on FeatureA, then FeatureB can only be activated if FeatureA is activated. If this is not the case it will prompt you with a message to activate FeatureA first. A sample Feature element tag is given below: <Feature Id="GUID" Title="Feature Title" Description="Feature Description" Version="1.0.0.0" Scope="Site" Hidden="false"> <ActivationDependencies> <ActivationDependency FeatureId="GUID" /> </ActivationDependencies> </Feature> If the dependent feature is hidden (to make a Feature hidden, set the Feature element's "Hidden" attribute to "False"), it will be activated automatically when the dependee feature is activated. For example if FeatureB has activation dependency on FeatureA and FeatureA is hidden, then FeatureA will be activated automatically when FeatureB is activated. Otherwise we need to activate the FeatureA manually before activating the FeatureB. Following are some important points which needs to be considered when dealing with feature activation dependencies: A visible Feature can have dependency on hidden Feature, but a hidden Feature cannot have dependency on visible Feature. It doesn't support circular dependencies (FeatureA depends on FeatureB and FeatureB depends on FeatureA). It has limited support for dependency chains. For example, WSS 3.0/MOSS 2007 supports more than one level in activation dependencies if a visible Feature depends on a second visible Feature that in turn depends on a hidden Feature. But it does not support more than one level in activation dependencies if the last Feature is visible—that is if a visible Feature depends on a second visible Feature that in turn depends on a third visible Feature.> If the dependent Feature is not activated, activation of the dependee Feature will fail. But if dependent Feature is hidden, then it will be automatically activated when the dependee Feature is activated. Cross-scope activation dependencies are not supported if following conditions are satisfied: If the dependent Feature is at a more restrictive scope. For example, a site collection scoped Feature cannot have an activation dependency on a web site scoped Feature. If the dependent Feature is not visible. For example, a web site scoped feature cannot be dependent on a site collection scoped Feature that is not visible in the user interface.

Interested in mastering  SharePoint ? Learn more about SharePoint Tutorial in this blog post.

ActivationDependency Element (Feature) Represents a Feature on which activation of the current Feature depends. <ActivationDependency FeatureDescription = string FeatureId = Guid FeatureTitle = string MinimumVersion = string SolutionId = Guid SolutionName = string SolutionTitle = string SolutionUrl = string> </ActivationDependency>   Attributes

Learning the Basics of Events in SharePoint Foundation 2010

An event receiver in Microsoft SharePoint Foundation 2010 is simply a method that is called when a triggering action occurs on a specified SharePoint object. Triggering events include actions such as adding, updating, deleting, moving, checking in, and checking out. SharePoint objects that listen for events—that is, event receiver hosts—include objects such as site collections, sites, lists, and workflows. Events are valuable tools for SharePoint developers. When a user performs an action that affects a SharePoint site, you can trap that action and respond to it with custom code. For example, if a project manager needs to be alerted when new documents or files are added to a given document library, you could write event receiver code to send an e-mail notification to the project manager, and then bind that code to the item-addition action on the document library. SharePoint Foundation 2010 provides enormous flexibility for detecting and responding to SharePoint events.

Events were first introduced in Windows SharePoint Services 2.0 but initially were supported only on document libraries. SharePoint events then were referred to as event sinks. In Windows SharePoint Services 3.0, the SharePoint events infrastructure took its current form, using managed event receivers. Event receivers improved on event sinks in several ways. They are easier to use; they have more event types; and they are supported on lists, content types, workflows, and sites. In SharePoint Foundation 2010, new list and web events were introduced; additionally, site collections can now act as event hosts, After events can now be synchronous, and event cancellation and impersonation has improved.

How SharePoint Events Work: All You Need to Know in One Paragraph

A SharePoint event receiver is bound to a SharePoint object—the event host—and responds to a user action by triggering event receiver code. You compile your event receiver code into a managed assembly—that is, a .dll file that is deployed to the global assembly cache.

Where Can I Use Event Receivers?

If you want to add behaviors to the operations that happen in SharePoint, you can use event receivers to trigger your custom code whenever a certain operation takes place. Table 1 lists the various operations on which you can plug your custom code.  

Table 1. Operations available to event receivers

What Are Event Receivers?

An event receiver is a piece of managed code that responds to SharePoint events when specific triggering actions occur on a SharePoint object. Triggering actions include activities such as adding, updating, deleting, moving, checking in, and checking out. To create an event receiver, you inherit from one of the event receiver base classes. SharePoint provides five event receiver base classes. (See Table 2 in the following section.) Note that each of the base classes supports only specified event hosts and events. You must select the correct event receiver base class for the host type you want to support. After you write your event receivers in your event receiver class, you must compile the receiver into a managed assembly and then place it in the global assembly cache (GAC). Finally, you must bind the event receivers to a suitable event host. Later in this article, we discuss event binding and the different methods with which you can bind events.

What Are Event Hosts?

Event hosts are common SharePoint objects that expect to receive events—in other words, objects whose event receivers "listen" for SharePoint events. These SharePoint event host object types include instances of common objects such as SharePoint site collections, sites, and lists. Each event host type has a specific set of event receiver base types from which it can inherit. Table 2 lists the event receiver base classes as well as the event host types that support each receiver, along with the events they support.  

Table 2. Event receiver base classes and supported events

Key Concepts in the SharePoint Event Model

In addition to the fundamental pieces of the event model—event receivers, event hosts, and the events themselves—the following are key concepts in the landscape of the SharePoint event model. Before Events A Before event occurs before the currently requested operation happens. For example, the ItemAdding event is a Before event that is raised before an item is added to a SharePoint list. Looked at another way, Before events are raised when an action occurs before SharePoint writes to the content database. This provides an opportunity for an event receiver to perform tasks before data is committed to a database. A good example of the use of Before events is performing data validation, because Before events fire prior to commitment of data. You can also use Before (or synchronous) events to cancel user actions—for example, if data validation fails. Event receiver code that is triggered by a Before event executes in the same thread as the code that is executing the user action that triggered it. For this reason, Before events are always synchronous. You can identify Before events because their member names end with the "-ing" suffix—ItemAdding, ListAdding, and so forth. After Events An After event is raised after the currently requested operation happens. For example, the ItemAdded event is an After event that is raised after an item has been added to a SharePoint list. After events trigger event receivers that execute after user actions are committed to the content database; they invoke code that runs after the content database has been modified. This allows you to execute logic that occurs after a user has completed a specific action. After events can execute either synchronously or asynchronously. If the After event is synchronous, it executes in the same thread in which the triggering action occurs. However, if the After event is asynchronous, it executes in a separate thread. You can identify After events because their member names end with the "-ed" suffix—ItemDeleted, WebProvisioned, and so forth. Synchronous Events A synchronous event is executed in the same thread in which the triggering action is occurring. For example, when the user adds an item from the SharePoint user interface, the event is fully executed before returning to the user and showing that the item was added. All Before events are synchronous events. Asynchronous Events An asynchronous event occurs at a later time than the action that triggered it, and it executes on a thread that is different from the one in which the triggering action is running. For example, when a user adds an item to a document library by using the SharePoint user interface, the event starts to execute before returning control to the user; however, there is no guarantee that the event receiver will finish executing before we show the user that the item has been added.

The SharePoint Events Pipeline

Figure 1 illustrates how SharePoint events occur with respect to synchronization and sequencing. Figure 1. SharePoint events pipeline   Notice the following details:

• Synchronous event receivers are called in sequential order based on the sequence number specified during event binding. This applies to both Before and After synchronous events.
• Asynchronous After event receiver threads are initiated in sequential order based on the sequence number. However, there is no guarantee that they will finish in that same order.
• An asynchronous After event can start at any time after its associated user action is performed. It may start before, at the same time as, or after the Web request is completed.

After a user initiates an action in the SharePoint user interface, and before SharePoint Foundation executes the user action, the synchronous Before events are raised. If there are multiple synchronous Before events, they are raised in the order specified by their sequence number. Similarly, synchronous After events are raised after SharePoint Foundation executes the user action. These, too, are raised in the order specified by sequence number. As you can see, all synchronous events are processed in the same thread as that in which the user action occurs.