I was recently asked about being able to change values of different variables like ConnectionStrings, Installation physical directory, app Settings etc during install time rather than build time, so I thought it might be worth while to de-mystify the concepts around Web.Config Transforms and Parameterization…
Geeks say Web.Config Transformation is a great feature of Web Deploy (aka MsDeploy), well the first part about being a great feature is true :-) but it is important to note that Web.Config Transformation is not a Web Deploy feature but it instead is a VS 2010 only feature. Web.Config Transformation is connected with Build configuration of MSBuild/VS/Team Build etc… Its XML transformation engine is wrapped in MSBuild and has a UI around in VS 2010 which yeilds following benefits:
- You get to tie Web.Config Transform with various build configurations and access it independently from Team Build.
- You can use it with any deployment mechanism like File System, FTP, FTPS, or Web Deploy
- You can use it in projects other than Web Projects where you want to transform XML files
If you are building a deployment web package (.zip) and know which environment you are building for then web.config transformation is great. This is the category where many of us fall coz we build for a release environment and need the right config file to go in that deployment package. For that matter many people are just fine creating web packages for the correct environment they are deploying to…
Now for others who want to be able to build just once and deploy to both test as well as staging/release environment then an embedded web.config file for one environment may not work. For this scenario there is parameterization.
Parameterization
Parameterization, unlike Web.Config Transform is Web Deploy (aka MsDeploy) only feature, which means that it will not work in non-Web projects or when you are using other protocols like FTP/FTPS etc. Parameterization from Web Deploy standpoint is a 2 step process
- Declare Parameters: You create a Parameters.xml file and pass it to Web Deploy while creating the package… In this file you need to indicate what file you want to parameterize (e.g. web.config), what variable inside the file needs to be parameterized (e.g. connectionString) and what would be the default value of the variable (e.g. release connectionString)… Using Parameters.xml file, Web Deploy will create an internal meta data file within your .zip package which guides Web Deploy to know what “Questions” to ask the person who is installing the .zip package…
- Set Parameters: When user is about to install the web package the value of the Parameters can be provided to Web Deploy via several means. In case you are using IIS Manager to install the package then the IIS Manager UI will automatically show the Parameters with filled in default values. If you are using Web Deploy command line to install the package then you can provide a setParameters.xml file to the commandline (in case of VS 2010 generated deploy.cmd file just having setParameters.xml file in same folder as the .cmd and .zip file is sufficient). The setParameters.xml file is a very simple name-value pair file in which you can provide the value of the parameter adjacent to its name.
In one of the future posts I will write more about how to use Parameterization for some canonical deployment scenarios, but hopefully this will lay the foundation of how to differentiate between build time transforms from install time parameters.
Conclusion
If you can know your environment settings during build time use Web.Config transformation.
If you would want to create deployment package only once and then enter the settings during install time then use Parameters.xml
VS 2010 actually uses a combination of Parameters and Web.Config transforms to provide you with a seamless experience (i.e. connectionStrings, IIS Application Name etc are already parameterized by default) so for most common scenarios you would hopefully not have to delve into understanding all the details but if you have any questions then of course feel free to ask here or via email…
Thanks
Vishal
