SharePoint Feature Receivers – the hidden details

Date:June 15th, 2010 Author: Tags: ,
Category: General, SharePoint Development Comments:2 ;

Warning –  this post is somewhat techie so if you’re not a developer you may want to go find something more interesting to do!

I’ve been doing some work with SharePoint Feature Receivers recently and found the official documentation to be somewhat … lacking.

SharePoint Feature Receivers allow you to run code when a Feature such as a web part or template is installed, activated, deactivated and removed. They are often used for installation/setup tasks that can’t be done using XML incantations in Manifest.xml, Elements.xml and Feature.xml.

I am not going to give a step-by-step guide to Feature Receivers (see the excellent How to add a Feature Receiver to a Feature from SharePoint dev wiki) but plan to detail information that I was struggling to find anywhere else.

I am only going to cover the scenario of a Feature encapsulated in a solution package and not installing features directly using STSADM -o InstallFeature as that requires the files are manually placed in the 12\Template\Features\ directory so is not as friendly as distributing .wsp files and is not something that you can really give to customers/server admins.


SharePoint Features can be targeted at the Farm, Web Application, Site Collection or Web Site scope. The target will effect things like where you can manage the feature activation from in the UI and at which point (and how many times) the Feature receiver events are called.

Scope Activate/Deactivate Features (2007)
Web Site Site Actions > Site Settings > Site Administration > Site features
Site Collection Site Actions > Site Settings > Site Collection Administration > Site collection features
Web Application SharePoint Central Admin > Application Management > SharePoint Web Application Management > Manage Web application features
Farm SharePoint Central Admin > Operations > Global Configuration > Manage farm features

SharePoint Feature lifecycle

Stage Event Trigger with STSADM -o Trigger with UI
Add to solution store AddSolution
Deployment to server/farm FeatureInstalled DeploySolution Central Admin > Operations > Solution Management
Activation to SCOPE FeatureActivated



See scope table above
Upgrade FeatureUpgrading (new for 2010) UpgradeSolution
Deactivation from SCOPE FeatureDeactivating

On RetractSolution if still activated when called



See scope table above
Retraction from server/farm FeatureUninstalling RetractSolution Central Admin > Operations > Solution Management
Delete from solution store DeleteSolution

SharePoint Administration Timer Jobs

Deployment and Retraction actually setup a timer job (which can be executed ‘immediately’ or at a specified time. If the “Windows SharePoint Services Administration” Service is not running then you will be warned that these jobs will not be executed and you can force execution by running STSADM -o ExecAdmSvcJobs on all servers in your farm.

Windows Identity

You can’t be sure which windows identity a feature event receiver will be running under as you don’t know if it will be called by STSADM (cmd.exe), “Windows Share Services Administration” timer service (WSSADMIN.EXE) or the WebUI (w3wp.exe with the app pools identity) – so ensure you are not relying on privileges (for example) that may be given to a logged on domain admin when using STSADM but not the app pools identity.

Event Windows Identity
Triggered with STSADM Triggered by UI
FeatureInstalled Logged on user Identity of Web Applications Application Pool.

Identity of “Windows SharePoint Serviecs Administration” service

or Logged on user if forcing by STSADM -o ExecAdmSvcJobs

FeatureUninstalling Logged on user Identity of Web Applications Application Pool.

SharePoint Context

Because you can’t be sure where the FeatureReceiver is being called from (command line, timer service, web ui) you can’t use the normal method of getting a SPSite/SPWeb object.

SPSite site = SPContext.Current.Site;
SPWeb web = SPContext.Current.Web;

Instead you can access the context through SPFeatureReceiverProperties.Feature.Parent see Matt’s handy extension method (beware though, it doesn’t cover Web Application or Farm scopes)

Note – you only get a SPFeatureRecieverProperties.Feature reference with FeatureActivated and FeatureDeactivating – its null for Installed and Uninstalling.

Scope FeatureActivated and FeatureDeactivating
Web Site SPWeb
Site CollectionSP SPSite
Web Application SPWebApplication

SPWebService though this seems a little useless – in most cases you would want to get SPFarm.Local

Tags: ,

2 Responses to “SharePoint Feature Receivers – the hidden details”

  1. Ravi Chinni says:

    Nice post, was looking for this info for long.
    Have a query…
    Would FeatureInstalled event get fired on each server on the farm?


  2. Punit says:

    Thanks a lot for creating this matrix. very helpful.

Leave a Reply

Anti-Spam Quiz: