I hate when we lose functionality in applications. I'm writing a pretty classic ASP.NET application right now. One assembly is the Data Access Layer, and I try to write enough unit tests to actually show that things stand a chance of working (both now and in the future). Also, I occasionally like to work at home, disconnected from work's servers (database and other). That means that I have MSSQL installed on my laptop, which has local copies of the databases that I would need. I also have my web.config checked into source control so others on the team can do a simple checkout and have the web site working with a simple build of the MSBuild script. Given that setup, how would one go about being a responsible unit tester? It seems that what I want is a way to set a default connection string in the main config file, and allow a user.config to (optionally) exist. If it did exist, it could override the settings that were in the main config file to point to a new database.

There is a new attribute, configSource, that looks promising because it can be used to redirect .NET from looking at the app.config (or web.config) and instead make it look at an arbitrary generic user.config file for its content. The problem with this approach is that it requires every machine to have this user.config file in the same place. What I want is more like what the old file attribute of appSettings provided. Unfortunately, the new tools in ASP.NET 2.0 get the connection string information from the connectionStrings section, so using the appSettings approach is out-dated.

For now, I'll use configSource, but it is a pain to have to tell each memeber of the dev team that they need to create their very own user.config file and place it in a certain directory, since this usage means that you wouldn't want to check user.config into your source control system.

Take a look at J.D. Meier's paper, How To Reference Web Services and Databases During Development, for some concrete samples on how this looks.