Azure web.config per environment

Solve your problem a different way. Think about the web.config always being static and never changing when working with Azure. What does change is your ServiceConfiguration.cscfg.

What we have done is created our own configuration provider that first checks the ServiceConfiguration.cscfg and then falls back to the web.config if the setting/connection string is't there. This allows us to run servers in IIS/WCF directly during development and then to have different settings when deployed to Azure. There are some circumstances where you have to use web.config (yes, I'm referring to WCF here) and in those cases you have to write code and create convention instead of storing everything in web.config. I have a blog post where I show an example of how I did this when dealing with WIF (Windows Identity Foundation) and Azure.

I agree with Mose, excellent question!

Visual Studio 2010 includes a solution for this type of problem, web.config transforms. If you look at your web role you'll notice it includes Web.Debug.config and Web.Release.config along with the traditional web.config. These files are used to transform the web.config during deployment.

The canonical example is "I need different database connection strings for development and release" but it also fits your situation.

There is an excellent blog post from the Visual Web Developer Team that explains how to use this feature (don't bother with the MSDN docs, I know how it works and still don't understand the docs). Check out http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx

I like this question !

For worker roles, I solved this problem by detecting the environment at runtime and launching my 'application' in a new AppDomain with a custom configuration :

• bot.cloud.config
• bot.dev.config
• bot.win.config

This is incredibly efficient !

I'd like to do the same with web projects, because using the Azure specific configuration is a lot of trouble :

• Both config are not in the same place, which is time-consuming when debugging
• You have to learn a new way of writing something that sould be standard
• Sometime you'll wonder if the app falled back on web.config because of a stupid syntax error

I'm still searching the right way to do that, like in this post