How can I easily use two different databases for debug and release scenarios?
I don't want to need to remember to change the data source connection strings every time I publish a new version of my application but I also don't want to test new code on the working database ...
Is there something like a debug / release switch?
I handle this by not committing web.config to my source control system. This prevents mistakes such as running a production system against a development or test database by accident.
I copy common config settings into a web-dev.config which does get committed.
If you're using Visual Studio 2010, Web.config transforms are the way to go.
The other way to do this is to remove the connection strings from your Web.config altogether and define them as properties (at the global level) in the IIS configuration.
By defining one connection string for your development IIS and another for your production IIS, they become environment dependant, and NOT a part of your build.
There are a few wrinkles related to Visual Studio getting confused and trying to create new connection string in your Web.config, when dealing with the DBML file of a LINQ2SQL definition, but these can be worked around.
Suggest keeping 2 .config files just for your connection strings. Name them prod.db.config and test.db.config. Each has the <connectionStrings> element with values specific to the environment that they're for.
The web.config has this element
<connectionStrings configSource="test.db.config">
Set the file properties for web.config as Build Action to None, once you're finished making changes to it. Take a copy of this, and deploy it to your application servers.
Whenever you're deploying releases, you're going to have to pay attention to configuration somehow. This strategy at least gives some visibility by filename on which connstring/database is being used in that environment.