I was writing a SharePoint feature that had to register a custom HTTP module. Naturally I started looking at the SPWebConfigModification class and soon had some code that looked like it would add my HTTP module to the httpModules element in the SharePoint web.config file. I compiled, deployed, and activated the feature, and sure enough it worked. My HTTP module was added to the the httpModules element, and the code was even smart enough to detect that if my HTTP module were already registered it would not be registered more than once.

I could have stopped there, but instead I stared getting fancy. I thought: I should check for the existence of the httpModules element itself. I recompiled, redeployed, reactivated the feature, and …. SharePoint died 🙁 I checked the web.config and found that the only HTTP module registered was my HTTP module. All of SharePoint’s default HTTP modules were gone.

I was dumbfounded. How could adding an element end up removing elements? I tried revising my code many different ways but to no avail. I looked at many code samples online that seemed to do the same thing I was doing and comments indicated that those code sample worked.

Finally, a theory occurred to me. There was one difference I could think of between the code samples I saw and my coed: my code was checking for the existence of an element that is created by default when SharePoint creates a new IIS web site, while the online code samples were all checking for the existence of completely custom elements. I did a little digging and found that SharePoint seems use a static web.config file template rather than the SPWebConfigModification infrastructure to generate its baseline web.config files. As such, SPWebConfigModification.SPWebConfigModificationType.EnsureSection will not detect the existence of  element provisioned through the file, because there are no records in the SharePoint hierarchical object store regarding those elements. For your reference, the template web.config file is located at:

C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions12CONFIGweb.config

Where does that leave a coder who needs to add entries to SharePoint web.config files? Sadly it looks like the code needs to have two different logic paths: one logical path for adding completely custom element that needs to check for each part of the element path being added, and one logical path that only checks for the existence of custom elements within an element path that is part of an element provisioned from the web.config template file referenced above. Using this split logical flow, I’ve generated a code base that can reliably add web.config elements to any part of a SharePoint web.config file.