ASP.NET MVC and multiple environments

Question

How does ASP.NET MVC, if at all, deal with or provide ways to create your application using multiple environments? For example:

1. Development environment (local machine, probably run via the built-in web server and talking to a local database)
2. Testing (runs against a preloaded databse with example data, although this part could be skipped and mocks could be used)
3. Production database on a real server with real data

Ruby on Rails has the concept of environments and "automagically" can deduce if you're in development or production, so you can specify your connection information (connection string) in a config file and the framework dynamically pulls the appropriate one. Is there a similar way of doing things with .NET MVC? If not then how are professional developers using .NET MVC handling different environments?

The only way I can think of is to manually add an "environment" global method (or use an enum, or something like that, maybe this is a use for something like the State pattern?) and store the different connection strings in the web.config file, and then create a base class which all data access classes derive from which provides a way to obtain the connection string for the current environment; this would then have to be set to production when the time comes to put the application live.

Is there another way? Most of the .NET MVC videos and articles I've seen don't even bother with separate environments but only use a development database and don't indicate how you do it in production.

Answer 1

I'd say this is really a question of your company's internal processes. Since every company is a little bit different it's hard to have a "right" generic way to support dev/test/alpha/production and/or other environments.

One way: Create a setup program that supplies the correct connection string based on the environment chosen during the setup process.

Another way: System Admin edits web.config file to supply correct connection string during install.

Yet ANother Way: Connection strings are stored in the system registry.

Even Another Odd Way: You have all your connection strings for all environments in web.config, then a setting in appSettings the tells you which one to use.

Depending on the client, I've done all of these. There are more but these are the more popular.

(One client wanted to store the connecting string in the data base itself. Really.)

Answer 2

There is a Publishing Wizard (in Visual Studio) wich let's you change parts of web.config for release build automaticaly. Wich happens to be the feature you are asking about. No magic thou.

Answer 3

What we have done is during our automated build process (Hudson), we alter values in web.config depending on which environment the build is for. Unfortunately there isn't a magical way to do this.

Answer 4

You can use alias for your database. You just point these aliases to different servers in the different environments. Stored in the registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\Connect if i remember right. Then you use the alias in the connectionstring.

In response to Jason's response: We use Enterprise Library Environments to configure the different environment paramters and via msbuild invoke the Merge Configuration Tool that generates the different configs for each environment. The deploy process picks the right config file depending on which environment to install.

Answer 5

Scott Hanselman described a neat solution to this problem here: http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx.