DevExpertise

Any time you deploy a custom development artifact, be it a web part, assembly, etc., you should do it via a feature and SharePoint solution – especially if we’re deploying it to a client.  Occasionally you need to run code when you activate or deactivate your feature by using a feature receiver.  Let’s say that you need add a custom configuration property that will change between deployments.  For example, one could write a generic feature that can be used for multiple projects and/or clients, and the only thing that changes is a path or value of something.  Instead of placing these in a web.config file, you can place them directly in the feature.xml file that defines your feature.  It’s a much better approach that mucking with the web.config, especially since you’d need to do it before activating the feature or installing the solution package.

Here’s an example of a feature I recently wrote for a client that ran when a new site was created.  The feature receiver executes when it’s activated, and configures custom permissions for the site.  I needed to add a farm administrator account to the site, but didn’t want to hard-code that into the actual code, so I put it in the feature definition:

Now, when my feature receiver code executes, I can retrieve these properties:

public override void FeatureActivated(SPFeatureReceiverProperties properties) {
    string farmAdminDomain = properties.Feature.Properties["FarmAdminDomain"].Value;
    string farmAdminLoginName = properties.Feature.Properties["FarmAdminLoginName"].Value;
    string farmAdmin = string.Format("{0}\\{1}", farmAdminDomain, farmAdminLoginName);

    // do something with values

Features are cool.