The titles a bit of a mouth full but I think this is a common requirement for deployments, where a release is built once and then deployed for different environments (e.g. first UAT then Production when finished testing).
When I first used Visual Studio 2010 I noticed the new Web.config.Debug/Web.config.Release transformation and thought it would be a handy feature, but after looking at build/deployment scripts for a project I’ve realised it’s useless for the kind of releases I do. I’ve never deployed directly from Visual Studio, it’s always been build the release via msbuild then copy the release onto target environment and use msbuild to perform deployment tasks. Setting environment specific configuration values was either done manually (nasty) or by xml transformations in msbuild script (messy). Web.config transformations seemed to fix this but require one unacceptable compromise, separate builds per environment for a single release, since the transformation is only applied at on build and it’s apparently not possible to use the same internal targets to transform the configs afterwards for deployments (please correct me if you know how). Since multiple builds makes tracing issues more difficult I wouldn’t want to risk using it.
As an alternative you can use Web Deployment Packages, which build and zip up your web application (asp/mvc/wcf etc.) with a neat script for deploying it straight onto the web server (creating virtual directories automatically) and using a “SetParameters.xml” file to hold environment specific configuration. If in your application you include a file called “parameters.xml” with all environment specific configuration (see here for details) when you build deployment package (by msbuild in the release or right clicking in VS) your “SetParameters.xml” will contain the names/default values of the configuration values. Its then a matter of maintaining environment specific versions of the SetParameters.xml file and using them when deploying the web packages by command line.