So I set off to write a custom SharePoint feature for a recent client project to adhere to best practices of course. I wanted to make sure that my custom feature was easy for the average joe with notepad skills to modify, so I made sure to add some app settings keys to the web.config so that my feature could read from them and be easily changed. For some reason, and I’ll chalk this up to a bad example I found when I was first learning about using the SPWebModifications, but in my code I called the “SPWebApplication.WebConfigModifications.Clear()” method.
Originally I started this feature off from another feature where I used this. The other feature had been deployed on a site with no other customizations, so the repercussions were not felt until now. Turns out that by calling the Clear() method, you end up clearing ALL web.config changes, whether you made them or not. According to MSDN the web.config changes are stored in the content db and this call will clear out ALL of those since it is a collection at heart. This happened when I installed a feature on a site that already had CKS:EBE installed (CKS:EBE is a feature itself), I got error messages and the CKS:EBE no longer seemed to be working although it was activated.
I figured it out by taking a clean site, activating CKS:EBE and then taking its web.config and backed it up. I then activated my feature and took a copy of the web.config. I then used a diff tool on the 2 web.config and noticed that the web.config AFTER my feature no longer had the CKS:EBE web.config changes. I then look at the “WebConfigModifications.Clear();” and commented it out and noticed that it no longer took out the CKS:EBE changes.
Moral of the story is to make sure you know what your doing when calling the WebConfigModifications.Clear() method, chances are you REALLY don’t need to call it.
FYI…Looks like I am not the only one who goofed this up http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/864dd894-c4cb-4815-a3de-8717d38da5ae/