I've seen and tried to use the config.<EnvironmentName> approach previously and as long as the project is established, I haven't had much issue. Where I usually run into issues is when a new section/ setting gets added to the config file. The developer adds it to their local one, and maybe remembers to add it to the .DEV one. File Diffs are the best way to ensure that all of the versions only differ by values, and because they are separate files there can be other formatting changes which need to be kept in sync.
With the approach I use, you have one config file, the one that gets used by the developer in the development environment. I then use MSBuild and XML Manipulation to set the values for any 'environment- specific' settings. This is somewhat similar to the approach Microsoft is apparently taking in Visual Studio 10 (http:// blogs.msdn.com/webdevtools/archive/2009/05/04/web-deployment-web- config-transformation.aspx). So there is a file that has a section for each environment, and then a set of properties in this section. This section includes -- Destination Deployment Directory, as well as Connection String, File Paths, E-mails, security Permissions, etc. While there is still a chance for error, the error is all in this file in the specific environment section. Glad your solution is working for you, just thought I'd give some perspective on why I chose the route I chose. As part of the process (when building my 'binary deployable package'), I take the config file that is checked into source control and replace all environment specific settings with INVALID VALUE. This serves two purposes. One, you can look at this altered config and scan through it to see if you missed anything that should have been environment specific. Two, if this binary package is just copied to an environment it doesn't just work. Using the build process to copy it to the environment will adjust the settings for that environment. This hopefully eliminates issues where one environment gets configured and is running against a different environment's settings. As I've been thinking, many of my customizations require some sort of 'build output' directory which, if you are actually going to store multiple versions would have a folder for each version. One java shop I worked used Maven for this sort of storage, NMaven at that time was not quite there and I haven't looked lately. As I mentioned originally, we have a separate SVN repository for this build output, only using source control to allow logging that nothing was 'altered' from the original package that was produced by the build process. This means that my 'tag' process is source control and binary and that's where all of the 'patching process' you mentioned comes in to play. It's just the standard source control tag/branch/trunk solution allowing CCNET to build the tags and branches to ensure that 1) they always get created. 2) they get created in a uniform manner with consistent naming. 3) only tags can be deployed from beyond the DEV environment. I stuggle a little figuring out how I can extend CCNET to accomodate this, since it is source control agnostic and this part of the process requires intimate knowledge of the source control system and process.
