Multiple environments in ASP.Net MVC 2

I a开发者_StackOverflowm learning ASP.Net MVC 2, coming from a PHP and some Rails background, and one of the only things that seems off to me is the way you manage config settings like connection strings, or endpoints for external services.

With the PHP framework my previous company used there was a standard format and convention for config files. My company was able to leverage this to make it so that a different config file would be loaded based on an environmental variable (which was set in the Apache config). This made it very simple and automatic to change any config setting based on the environment. As far as I know, Rails has some version of this functionality built-in.

I am familiar with the app.config and web.config files of the .Net world, but is there a way to have these change based on the environment, preferably automatically, and with various levels of granularity? The whole config system seems very anemic compared to what I'm used to.

I could probably hack something together to accomplish this, but I wanted to see what approach people are taking in practice, or if there's some standard tool people are using.

There is web.config transformations.

I am likely wrong, but I seem to recall that they wouldn't get applied if one simply started the application with the "Start Debugging (F5)" button inside Visual Studio, making the feature seem impractical for a lot of uses.

You could try something like this: Managing Multiple Configuration File Environments with Pre-Build Events

Obviously, you can run your in environment in "Debug" vs "Release" mode. The ENV variable in Rails and similar conventions in PHP are clearly one of their strengths. As with any choice theres always a trade off and thats one of them. When I'm in rails I can appreciate the ability to load up your ENV variable (test, dev, production...) with the appropriate gems and such. Its great. When I'm in rails, theres also a considerable difference between VS intellisense, probably the best thats out there.

That said, some tricks I've seen have been coding in MachineName properties into appropriate connection strings and the like so WebConfigs can easily be passed between different developers and servers etc...

Personally I use machine.config to manage environment specific settings. This file contains machine specific settings.

If you don't have dedicated machines for each environment but instead you are using different web sites in IIS you could have a root web.config file located at the root of each web site containing environment specific settings.

Basically inside this global configuration file I store key/value pairs containing the names of my SQL Server, Web services server, ... which vary across environments and then in my application I use those keys to construct the final connections strings, http web addresses, ...

Once those global configuration settings are in place you can deploy the exact same application files with web.config among all environments.