It is very common for a web applications to have different environments like follows:
There are different settings, configurations related to the application in web services (backend) or frontend which use a set of configuration defined under “Web.config”.
Web.config plays an important role in storing all the settings and configurations related to the web application. There are multiple instances where web.config defines information that controls module loading, security configuration, session state configuration and application language and compilation settings.
Connection strings are also present in web.config which vary according to the various databases used by development team.
As tracking of various settings and configuration seems (and it indeed isJ) a daunting task, it makes complete sense to have a mechanism which will provide a seamless way to pick the correct configurations according to the environments.
Enter Web.config transforms
Web.config transforms include XML markup that defines how to change web.config when it is deployed. These different changes are derived from project build configurations.
Default build configurations are Debug and Release, while custom build configurations can be created.
When a project is created, “Debug” and “Release” are the pre-existing build configurations.
You can create custom build configurations easily by using “Configuration Manager”.
Creating custom build configuration
In Visual Studio 2012, open a solution, and click on the drop down list for “Solution Configurations”.
Click Configuration Manager..
Configuration Manager dialog will be shown.
In the drop down list for ‘Active solution configuration’ select ‘<New…>’ and provide a name for the new configuration.
If you wish, you can use settings from other build configurations if applicable.
When done, we will need to add the config transforms related to the new configuration created.
Adding Config Transforms
Right click on web.config in the corresponding solution to see the context menu.
Select “Add Config Transforms”.
This will result in creating the transforms for the related build configuration.
For instance, I have created build configurations as – ReleaseStagingPM, ReleaseStaging, and ReleaseProduction, in addition to pre-existing Debug and Release.
The config transforms are created as below:
As shown, with respect to each build configuration, there is one web.config.
So? What it has for me?
With the use of XDT transforms, web.config transforms provide a very simple and efficient way of managing your configuration parameters.
For instance, my original web.config contains following:
<endpoint address=”http://localhost:50047/MyService1.svc” binding=”basicHttpBinding” name=”BasicHttpBinding_IMyService1″/>
There is a web service called “MyService1.svc”. For the purpose of development and frequent debugging, I am pointing it to http(colon)//localhost(colon)50047/, which is the development environment.
Now, when I configure my respective “transformed” web.config, I use XDT transform to let web.config transforms know what pointing I am intending to change.
This is achieved by following line of code.
<endpoint address=”http://www.MyDomain.net/MyService1.svc” binding=”basicHttpBinding” bindingConfiguration=”BasicHttpBinding_IMyService1″ name=”BasicHttpBinding_IMyService1″ xdt:Transform =”Replace” xdt:Locator =”Match(name)”/>
Now, if you observe the last two parameters, they employ XDT transform “Replace” to replace the line of code, by identifying “name”. It is highlighted in bold black font.
More syntax for XDT transform can be found at: http://msdn.microsoft.com/en-us/library/dd465326%28v=vs.110%29.aspx
As a result, when I am building the web application, the “transformed” web.config will have above endpoint instead of my development environment endpoint.
In this way, an efficient use of web.config transform enables quick changes in web.config according to environments. This leads to faster deployments.