SPWebConfigModification without hardcoding the modifications


Not sure if this has been done or not but it seems unlogical to have the web.config modifications hard coded into the Feature Receiver, so I whipped up a quick mechanism to read it from an external config XML file. Feel free to use and improve as desired.

The code uses LINQ to XML for reading the config file so .NET Framework 3.5 is a requirement on your SharePoint server. If you can't have it you'll need to modify the code to use .NET Framework 2.0 XML classes.

Feature Receiver

Doesn't contain anything rather than a call to the DeploymentUtility for handling the modifications.


Whipped together over time after trial and error. Abstracts the SPWebConfigModification class and provides the following methods:

  • AddNodeValue(name, xpath, scriptResource): used for adding elements.
  • AddSystemSection(name, xpath): used for adding or ensuring a section. These will NOT be deleted when calling the removal method.
  • AddCustomSection(name, xpath): used for adding or ensuring a custom section that WILL BE deleted when calling the removal method.
  • AddAttribute(name, xpath, value): used for adding attributes to elements.
  • SaveWebConfig(webApp): saves the batch of modifications to the web.config file(s) for the specified Web Application.
  • RemoveWebConfigEntries(webApp): removes the modifications for the specified Web Application and current 'Owner'.
  • DeploymentUtility

    Acts as intermediary layer between the Feature Receiver and the WebConfigUtility. From the Feature Definition it will read the Config XML file using LINQ and will invoke the correct method of the WebConfigUtility via reflection.

    For the structure requirements of the Config XML file see "webconfig.xml" below.


    Just your ordinary Feature.xml file. It has two required properties to specify the owner and the webconfig file name:

    <Property Key="WebConfig.FileName" Value="webconfig.xml"/>
    <Property Key="WebConfig.Owner" Value="VNTG.AjaxConfig" />


    Contains the modifications that need to be applied. This file needs to be built using the following structure:

    <action name="MethodToInvoke">
    <param name="MethodSignatureParam1">
    <param name="MethodSignatureParam2">


    ! The action name has to be identical to the 'Add' method you want to invoke
    ! The number of params must be identical to the 'Add' method number of parameters
    ! Put the params in the correct order as required by the method signature (the 'name' attribute is just for clarity)


    I have packed the sample feature receiver (can be used for activating Ajax for .NET 3.5) with all classes and files available for download. Since this will probably be part of a larger solution you'll need to incorporate those classes in your own code if desired.

    - Visual Studio 2008 project


    • WSS 3.0 or MOSS 2007
    • .NET Framework 3.5 (because of LINQ)


    Why two helper classes ? Just didn't have time to whip it up into a single class ;)

    I take no responsability for anything that happens while using this code.



    Friday, 3 Oct 2008 08:37 by Ryan McIntyre
    Here's another option I put together a while ago which doesn't use LINQ, so no .NET 3.5 requirement. Same concept, though. http://randomdust.com/blogs/ryan/archive/2008/07/21/web-config-featurereceiver-update.aspx

    Sunday, 28 Jun 2009 02:57 by Jennifer
    Steven, fyi, I just tried you solution and found that it has a couple of problems: - there are some funky chars in the binding redirect statements, which probably also cause that these lines are not removed when deactivation the solution - the section gets removed when deactivating (same problem as the 3.5.config solution on codeplex), which causes problems when trying to reactivate again. Best regards jennifer (finalcandidate.com)

    Monday, 29 Jun 2009 10:32 by Steven Van de Craen
    Thanks Jennifer, If I recall correctly that is a known issue and not easily fixed ? Have you found a solution / workaround ?

    Tuesday, 30 Jun 2009 04:58 by Jennifer
    Hi Steven, yes, in the end I found something within the SharePoint Guidance project that looks like it's working fine ...here's the link to my post that has the .wsp I built using that approach: http://blogs.sharepointdam.com/jen/archive/2009/06/30/WebConfigModifications.aspx Sunny greetings from Barcelona Jennifer

    Friday, 17 Jul 2009 12:42 by JB

    Thursday, 1 Apr 2010 02:24 by

    Wednesday, 8 Jun 2011 04:14 by Hobby
    Hi Steven, Thanx for the good article. You have to "clense" SPWebApplication.WebConfigModifications collection before you proceed with update to prevent corruption of the entire collection. I did it like this: public void SaveWebConfig(SPWebApplication webApp) { RemoveWebConfigEntries(webApp); foreach (SPWebConfigModification modification in _mods) { webApp.WebConfigModifications.Add(modification); } _mods.Clear(); webApp.Update(); webApp.Farm.Services.GetValue().ApplyWebConfigModifications(); } public void RemoveWebConfigEntries(SPWebApplication webApp) { Collection webConfigModifications = webApp.WebConfigModifications; int count = webConfigModifications.Count; for (int i = count - 1; i >= 0; i--) { SPWebConfigModification item = webConfigModifications[i]; if (item.Owner == Owner) { webConfigModifications.Remove(item); } } webApp.Update(); webApp.Farm.Servers.GetValue().ApplyWebConfigModifications(); webApp.Farm.Servers.GetValue().Update(); } cheers :-))

    CAPTCHA Image Validation