Manpreet Alag‘s recent post, SPWebConfigModification does not work on Farms with multiple WFEs, has been making its rounds on Twitter and the link blogs. A post title like that is sure to get attention, but is it really true? After looking a bit closer, I don’t believe it is.
The post suggests that this doesn’t work:
SPSite siteCollection = new SPSite("http://MOSSServer/");
SPWebApplication webApp = siteCollection.WebApplication;
// ...
webApp.WebConfigModifications.Add(modification);
webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();
But this does:
SPWebService.ContentService.WebConfigModifications.Add(modification); SPWebService.ContentService.Update(); SPWebService.ContentService.ApplyWebConfigModifications();
Drawing this final conclusion:
Instead of adding modifications to WebConfigModifcations of SPWebApplication object, we are using SPWebService.ContentService to call ADD and UPDATE methods. Whenever required, it is always advised to use SPWebService.ContentService to make the modifications rather than accessing Farm instance through SPWebApplication.
The suggestion is that there’s a problem with applying the changes through webApp.Farm. But that Farm is just SPFarm.Local:
public SPSite(string requestUrl) : this(SPFarm.Local, new Uri(requestUrl), false, SPSecurity.UserToken)
{
}
So the last line is essentially equivalent to this:
SPFarm.Local.Services.GetValue<SPWebService>()
Taking a peek at ContentService, we find this definition:
public static SPWebService get_ContentService
{
if (SPFarm.Local != null)
{
return SPFarm.Local.Services.GetValue<SPWebService>();
}
return null;
}
The modified sample isn’t actually doing anything different to apply the changes! So the problem is either in how SharePoint handles Web Application-scoped web config changes, or that the changes aren’t being applied correctly. The latter is much more likely than the former, and indeed the solution is actually quite simple: just look for the only other significant difference between the code samples.
webApp.WebConfigModifications.Add(modification); webApp.Update(); // Oops! webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();
A quick PowerShell session or console app would have verified that the config changes weren’t being saved to the database.
So what have we learned?
- Always call Update() after making changes to an SPPersistedObject (like SPWebApplication or SPWebService).
- SPWebService.ContentService is a shortcut for SPFarm.Local.Services.GetValue<SPWebService>.
- Check your code carefully before blaming the SharePoint API!
Solutionizing .NET 
May 26, 2009 at 10:29 am
No, SPWebConfigModification doesn’t work fine–at deployment-time it’s unreliable, and I don’t think it’s a good idea to store your config in SharePoint’s web.config anyway (another topic.) My first production deployment involving web.config modifications (installing a single HttpModule) failed, requiring ‘extra, unplanned deployment love’ to get working.
The other point about using the API correctly is a good one, but I can’t agree with the “SPWebConfigModification is reliable” conclusion.
May 26, 2009 at 11:00 am
I never said it’s “reliable”, only that it’s “fine”. :) More specifically it’s “fine” in the sense that the other post said it isn’t, i.e. switching to ContentService won’t save you.
I’ve never had any problems with it myself, but I haven’t tested extensively…
May 26, 2009 at 4:48 pm
There are some new features with .NET 4.0 release that I was demoed last week which are available now called MSDeploy. This has a much more elegant solution to updating the web.config. When I get time I’d like to see how this could help SharePoint developers!
May 27, 2009 at 6:04 am
Have to disagree with Peter here.. in all the solutions I’ve done that required web.config modifications, I’ve used the SPWebConfigModification with success (deploying/retracting/redeploying). The only thing about it is that it’s quite hard to get it right and thus you are confronted with undesired behaviour, especially with multiple WFE’s.
Keith, I really love it when you do these posts.. wish you were lived in the Netherlands (or even Europe for that matter! ;)
May 27, 2009 at 2:46 pm
Personally I have a love/hate relationship with SPWebConfigModification. I have rolled out plenty of stuff where it has worked fine, but I have also had a few solutions (the major minority though) where it doesn’t consistently deploy the change across every server in a farm. The fix in that case was usually restart the admin and timer services and run the same code again and that has worked for me every time – so I think perhaps the issue isn’t with SPWebConfigModification, rather SharePoint deployments on the whole (and I know there are plenty of people with issues on that front so I’m not gonna open that whole can of worms here).
I have also found that while you can easily add stuff through SPWebConfigModification, it doesn’t always take sections back out of the web.config file. For example if you use it to add the new sections to support AJAX and then run code to pull them back out, it will remove the SPWebConfigModifications from the collection, but the top level sections stay put – which causes a big problem because the description of all those sections has come out fine, so your web.config file then becomes unusable.
I blogged my thoughts on this stuff a while back though, if anyone is interested in reading it you can find it at http://blog.brianfarnhill.com/2008/06/13/updating-sharepoints-webconfig-file-from-code/
May 28, 2009 at 5:44 pm
[…] SPWebConfigModification Works Fine […]
June 25, 2009 at 5:47 am
Great post, Keith!
April 28, 2010 at 3:22 pm
[…] In my case I have used a method which should work over multiple web front end servers. […]
May 14, 2010 at 2:14 pm
[…] SPWebModification Works Fine Possibly related posts: (automatically generated)Using SPWebModification to modify the web.config (Part 1) […]
December 5, 2011 at 8:07 pm
[…] – I found this blog post (https://solutionizing.net/2009/05/26/spwebconfigmodification-works-fine/) which suggests that the ContentService class simply provides a constructor to handle if the Farm […]