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.
2 responses to “Dealing with corrupt WebConfigModification entries.”
This is very helpful but meant for a DEV environment as it will also remove web config mods from other solutions. For example, I iterated through the WebConfigModifications in code and found Nintext mods as well as my own.
Good point! Yes – I was doing this on a dev machine. That environment tended to get get corrupted more than others, especially since it was a shared dev environment. A couple of thoughts. From my understanding, this will only clear the modifications that are in queue that have not been applied. That would mean that the corrupt entry was in queue and not yet applied to the web.config. I guess there is a chance that you could clear out any legitimate entries that might have been backed up because of the bogus entry but then you should have received an error from those entries also. From what I can tell, this does not remove any web.config entries that have already been committed to the web.config. Those entries have to be removed by code.
Thanks for your comment.