I’ve started a new software development project recently, and the entire solution will be hosted on Azure PaaS resources, including Web Apps. Part of application development involves storing configuration settings for the application. Notably, this could include the database connection string(s). In the case of the app under development, there are Azure Active Directory, Azure Key Vault and Azure Storage Account settings (to name but a few).
Over the years, storing configuration settings in web.config has been a common practice. Visual Studio enhancements in recent versions, especially Web.config transformation, have made web.config deployment to different environments (such as test, QA, staging and production) also much easier.
On Azure, things get especially interesting though. In addition to the many settings for the different Azure resources, the concept of deployment slots on a Web App allow for different versions of the code to run in a single VM. This is useful for test, QA, A+B testing, etc. However, you might very well have the same Visual Studio build configuration for code that lives in different deployment slots.
On top of that, there are some settings that will keep the same values across deployment slots (for example, your database connection string would not change for A+B testing), but will change for other deployment slots. You’d quickly end up with an exponentially growing number of Web.config transformation files and the added risk of accidentally deploying an incorrect build configuration to a particular slot.
So, instead of trying to create Web.config transformation files for every combination of settings, you would instead add your connection string(s) and app setting values to the Azure Portal UI. This will not actually update the values in web.config, but using the standard ConfigurationManager API, will cause those values to be used instead of those found in web.config. Don’t worry, you don’t need to specify all app settings keys in the Azure Portal. Add only those you care to have Azure change for you based on the deployment slot.
In addition to being very convenient, there are also security benefits, as described in this post:
http://blogs.msdn.com/b/subodhpatil/archive/2013/08/02/importance-app-settings-in-azure-website-portal.aspx
A full walk-through of creating deployment slots and how configuration settings can swap or “stick” to deployment slots, see this tutorial:
https://azure.microsoft.com/en-us/documentation/articles/web-sites-staged-publishing/
Sven Aelterman 