Here is one of the biggest problems with SharePoint - it's largely broken web.config management prowess. I won't actually document every single issue here, because my good friend Reza has done a fantastic job at pointing those out. But, in a large SharePoint project involving lots of custom code, one of the most common changes you'd need to do is .. APPSETTINGS!

Yep, it's that pesky <appSettings/> node in your web.config where everyone and their daughters will want to store configuration information such as connectionstrings, wcf endpoint addresses, etc. Now, some people say .. ahh you should store all that config information in a list.

I say, are you kidding me!? No seriously! Why? A list can be changed through the UI, or well, even accessed through the UI. While a blinded by faith SharePoint fanatic will say .. it makes it more manageable, a more practical person will say, there is a reason why these settings live on a server file that will never get rendered through IIS on a browser. An end-user, non-deploy person should never be able to change such settings. For serious, you don't want internal server names etc. to be shown over the UI .. in any case. Not to mention, you have to protect that list, break security inheritance, impersonate to read, ugh! never mind!

So, here is a much better way.

a) Ue SPWebconfigModification to make the following entry.

<appSettings file="appSettings.Config"/>

b) Create a new solution, which deploys a file called "appSettings.Config" in the web root. This can be very easily done using WSPBuilder where you simply place a 80 directory in your solution, and throw the appSettings.Config in there. This will reliably deploy the appSettings.config to all the web front ends on the given web app.

c) Create an appSettings.Config file as follows -

   1:  <?xml version="1.0"?>

   2:  <appSettings>

   3:    <add key="kutta" value="kamina"/>

   4:  </appSettings>

d) Use it in your code in the usual fashion -->

   1:  Response.Write(ConfigurationManager.AppSettings["kutta"]);

This is much better than dealing with the intricacies/idiosyncracies of SPWebConfigModification