Build once and deploy to multiple environments with msdeploy & Visual Studio 2012

Question

Working on centralizing configurations, app settings and connection strings, for multiple solutions, while also switching over to use msdeploy from command line to deploy web apps. Ideally I would want to build the packages once, and get up-to-date configurations as the packages are deployed to each environment. I need some advice on the best approach to take.

1. Use Parameters.xml and SetParameters.xml file to dynamically swap out settings and connection strings. See http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.html
2. Use machine.config or server level web.config files to store common app settings and connection strings.
3. Use packageweb NuGet package from https://github.com/sayedihashimi/package-web which enables using web.config transforms with msdeploy.
4. Use file or configSource attributes along with SetParameters to point to different config files, but must be relative from web root.
5. Use publish profiles. See Deploying an existing package using publish profiles

Thanks

Answer 1

I can elaborate a bit on options #1/#3 and compare them. The previous reply was not accurate in stating that you have to build multiple times with PackageWeb, you only need to build once.

Option 1: Parameters.xml and SetParameters.xml

In this approach you will create a parameters.xml file in your web project which will declare additional Web Deploy parameters.

When you build the Web Deploy package the parameters declared in parameters.xml are created in the package. When this web deploy package is created the web.config file will be transformed based on the build config (and now potentially a profile specific transform as well).

You can use that package and a setparameters.xml to publish the package specifying the Web Deploy parameter values. You can create different setparameters.xml files and use that along with the same package to publish to multiple destinations. To publish using this technique you can use either the deploy.cmd which VS generates or call msdeploy.exe with the correct set of parameters.

Option 3: PackageWeb

PackageWeb extends the package process so that when you create a Web Deploy package the web.config transforms are included in the package as well as an assembly which can execute the transforms.

In addition to this when you create a web deploy package a publish-interactive.ps1 file is generated. You can use this file to publish your package. It will prompt you for; the web.config transform to be applied, the web deploy parameter values, and the web deploy endpoint info itself. When you run through a publish the values you gave are saved to publish-configuration.ps1.readme. You can remove the .readme and publish-interactive.ps1 will use the values from that file to automate the publish. You can also specify the file to be used for settings.

If you created a parameters.xml file when the web deploy package is created by VS it will result in web deploy parameters being included in the package. PackageWeb will pick those up and prompt you for those as well.

So what are the differences between these approaches?

With Option #1 the web.config which gets into the package is already transformed. You will not have an opportunity to transform the file again. With both approaches you can specify web deploy parameter values though so that may suit your needs. If you are modifying big chunks of XML from one env to the other then the web.config transforms may be beneficial. So PackageWeb may be a better choice.

With Option #1 you have to manually create the SetParameters.xml file. With PackageWeb you can run through the process using the WhatIf option. You will be prompted for the values and it will create the settings file for you.

You can easily automate both approaches. PackageWeb essentially builds on the parameters.xml/setparameters.xml technique and offers a super-set of the functionality.

If you want to keep things as simple as possible with the least # of moving parts I would recommend option #1, because you can directly call msdeploy.exe if needed.

If you want to simplify automating the publish and you prefer PowerShell to a standard command prompt then try out PackageWeb.

I have a 5 minute video on PackageWeb at http://sedodream.com/2012/03/14/PackageWebUpdatedAndVideoBelow.aspx. If you are publishing web deploy packages I encourage you guys to try it out. If it doesn't meet your needs please let me know because we may use what we learn in PackageWeb later in a more formal way.