Dealing with corrupt WebConfigModification entries.

Recently, I came across a problem.  I had created a new SharePoint Designer Custom Action and I created a feature solution package to deploy it to the production farm.  In testing it in a dev environment, I kept getting errors from the code I was using to make the appropriate web.config entries.  A custom SPD workflow action requires an ‘authorizedType’ entry in the web.config.  I have code in my feature receiver that will create a WebConfigModification entry in the WebConfigModifications collection and then use the SPService to apply the modifications.  (MSDN).  My problem was that someone had created a corrupt entry in the collection and it kept erroring out before executing my change.  It took a little understanding of how this works to find the solution to the problem.

The WebConfigModifications are a persisted object. That means that they remain until they are operated on.  In essence, it is a persisted queue.  Each entry is related to a SPWebApplication and added to the queue.  To remove the offending entry, I had to identify which web application the entry was registered with.  I just started going through every web application in my farm.  You could iterate through each application but in my case, I just hard-coded the URL for each application.  Here is the code that I used to clear the corrupt entries:


string siteUrl = @"http://localhost:44689";
SPSite site = new SPSite(siteUrl);
SPWebApplication webApp = site.WebApplication;
webApp.WebConfigModifications.Clear();
webApp.Update();
SPWebService service = SPWebService.ContentService;
service.WebConfigModifications.Clear();
service.Update();
service.ApplyWebConfigModifications();


I created a console app and put the code above in the Main() method. I kept executing the code using different web application URL’s until it executed without any error. Once I didn’t get an error, I was pretty sure that I had cleared the bogus entry. The next time I ran my feature code, it executed flawlessly!

A couple of notes. Obviously, this code is meant to be executed on the server and not a client. My dev machine has a single WFE. I would think that the best place to execute this would be on the same machine where Central Admin resides. Also – this was for a problem on a MOSS (WSS3) install. I am sure that it works the same in SharePoint 2010.

You can find the correct URL’s in IIS for each web application on your server. In my case, it was a shared development machine so there were many web applications executing under many different ports.