How many times have you experienced a chilling moment when something goes terribly wrong with the system you just touched and you don't have any clue what would've caused it?
In a SharePoint installation with multiple web applications and several custom solutions there may be a lot of action going on in web.config files. Even the slightest validation error in these files will bring the web application to a halt. This and the fact that the SPWebConfigModification class has a will on its own make the task of coordinating web.config modifications a very touchy business.
Recently one of my colleagues reported that after installing one of the SharePoint solutions, entries installed by another solution were disappearing, leaving the web application in chaos. Logically I started poking the features in the SharePoint solution, which was "causing" the issue, but this lead me to no where. I only learned that when you call:
The web.config files for all web applications get rewritten, regardless of which web application is being updated. But this turned out to be a "feature" of SharePoint. Then I started investigating what other web.config modifications are being created by the rest of the solutions on this server. Luckily most of these belong to our company, so I was able to pull up the code. All features worked correctly when executed separately, but still in a particular sequence some of the web.config modifications were disappearing. And there it was ... one of the features was adding the modifications correctly:
SPWebConfigModification modification = new SPWebConfigModification();
modification.Path = "...some path..."
modification.Name = "Example"
modification.Value = value;
modification.Owner = "Owner"
modification.Sequence = 0;
modification.Type = SPWebConfigModification.SPWebConfigModificationType.EnsureChildNode;
then applying the changes to update the web.config:
But there was no webApp.Update() to persist the changes in the SP database!
It turns out it is very easy to omit this part, because when you develop or debug such feature all will work fine until something does not flush the application pool thus disposing off the newly created SPWebConfigModification. The next solution or feature that calls ApplyWebConfigModifications will force reapply all modifications pulling them from the SharePoint database. For some features this actually might be a welcome side effect, but unless this is not the case you need to call webApp.Update() to permanently save the modifications to the SharePoint database.
One mystery solved. Next, please!