Differentiating web.config between dev, staging and production environments

With the new VS you can use web config transformations.

Read more here: http://msdn.microsoft.com/en-us/library/dd465326.aspx

My approach has been to have multiple config files. I put all environment agnostic stuff (i.e. doesn't matter if dev, staging, or production) in the web.config file. Anything that is specific to the environment (i.e. database connection info, logging, debug settings, etc.) I put into a local.config file specific to the environment. You can then include the local.config settings in the web.config using configSource (http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx)

Web.config can then be checked into source control. Don't check in the local.config files - that forces you to deploy the correct one in your deploy scripts.

I use CruiseControl.NET/NAnt and NAnt has an XMLPoke task that allows you to go in as you're building and alter any config setting using XPath queries.

So in each of my build targets (DEV, UAT, STAGING etc) I set a bunch of properties and then call the master build target. The master build target takes the values of all the properties and XMLPokes them into the config and builds.