Thursday, March 20, 2008


This Month: Intro to SharePoint Designer

When / Where?
Wednesday, April 2, 2007   - 6:30 PM EST

Orlando Public Schools Administrative Offices
445 West Amelia Street
Orlando, FL 32801 – 1129

How to sign up?

Who Should Attend?

Developers, designers, power users, architects,

What will be covered?
In this session we will dive into SharePoint Designer. 

Who will be speaking?
Scott Schwarze

Disappearing web.config entries

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!


Orlando Code Camp - Sold Out!

Just noticed that the Orlando Code Camp is sold out. This is going to be another super-charged and totally free event organized by our friends at I signed up as a speaker with my two sessions from South Florida Code Camp. They were very well received in South Florida, so after some adjustments I decided to give them one more run. Come with your experience and ideas and lets talk about how we can avoid some common frustrations in SharePoint development.

I'll be carpooling with some Brevard developers, so if you need a ride or you want to save on gas contact me today or tomorrow to give you the details.

For details: