Lars Nielsen's Discoveries

April 28, 2010

Using SPWebModification to modify the web.config (Part 6)

Filed under: Development,SharePoint — Lars Nielsen @ 8:00 pm
Tags: , ,

This is one of a series of posts – start here to read the whole series

In this post in the series I’ll look at how to make the magic happen and actually update the web.config files.  I’ll do this in the feature receiver code of a web application feature, so that when you activate / deactivate the feature on a web application, it’s web.config will be updated appropriately.

To do this you need to create a Feature Receiver in SharePoint.  This is a special class that enables you to run your own code when a feature is activated or deactivated through the SharePoint GUI.  This is a good explanation of how to create a feature receiver.  In this case, when the feature is activated or deactivated, we want to run the code that updates the web.config file.

If you’re using WSPBuilder then you can use Visual Studio to add a new feature with a new feature receiver.  The tool will create the XML files and the C# class file that you need.  You need to decide what to call your feature, and what its scope is.   Typically for most features the scope is usually site or site collection.  But I had problems with security and permissions in my production environment unless I scoped the feature to a web application (see next post for details).  So I set the scope to web application.  There’s some sense in doing this.  If you have the feature scoped to a site collection, then when you activate it and update the web.config,  all the sites in the web application will get the web.config change (not just the one where you activated the feature).  In other words, even if the scope of the feature is to a site collection, the scope of the change that it makes is to the web application.  So I figure you may as well scope the feature itself to the web application.

OK so let’s look at the implementation.  Well having built up quite a lot of the functionality in the base classes already, the remainder is quite simple.  Firstly we need the standard four override methods for any feature receiver:  activated, deactivating, installed and uninstalling.  We’ll use the activated and deactivating methods to make something happen when someone clicks the Activate button next the feature.  Because this feature is scoped to the web application, you need to go to the Central Administration to activate it.

public override void FeatureActivated(SPFeatureReceiverProperties properties)
     ProcessChanges(false, properties);

public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
     ProcessChanges(true, properties);

ProcessChanges method

The ProcessChanges either adds or removes the line in the web.config depending on whether the boolean argument is true or false.

The method sets the properties that we want, and then adds or removes it from the web.config.

private void ProcessChanges(bool removeModification, SPFeatureReceiverProperties properties)
     string featureID = properties.Feature.DefinitionId.ToString();
     ProxyConfigModification mod = new ProxyConfigModification(featureID);
     // Set the new values of the attributes of the proxy element
     mod.BypassOnLocal = "True";
     mod.ProxyAddress = "";
     mod.UseSystemDefault = "False";
     SPWebApplication parentWebApp = properties.Feature.Parent as SPWebApplication;
     if (removeModification)
     // update changes to the web application configuration

The highlighted lines are worth looking at – this is where the changes to the web.config file are actually written down on the file itself.  Notice that you have to call the update() method on the web application – this is important otherwise SharePoint won’t update its configuration database properly.  When I looked into how to write the changes down to the file, there seems to be a lot of debate about how to call the ApplyWebConfigModifications method.  For example in Mark Wagner’s article he suggests code like this:


In my case I have used a method which should work over multiple web front end servers.

That covers all the code and how it works – in the next post I’ll look at deployment.


1 Comment »

  1. Great Work! Thanks!

    Comment by Whistler Web Design — May 26, 2010 @ 8:15 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: