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.