Can I package a website with a publish profile using msbuild and skip the web.config transforms?

4
votes

I have a solution of websites with three publish profiles, which we use to transform the connection strings for each target environment:

  • Test - localhost connections, no transforms, defaults are checked in
  • Staging - a VM environment
  • Production - the real deal

We also have some app settings that need to be transformed for each environment. So, we used regular, build-configuration-based transforms.

  • Debug - transform settings for Staging
  • Release - transform settings for Production

This leaves us in a pickle when we try to package the Test profile. We package it so the testers can deploy on their systems from build artifacts instead of source code. But, the Test package picks up the Debug app settings transforms.

Is there some way to tell msbuild to package the website, using the Test profile, but to skip the config transform? Or should I restructure the build configurations around the environments? (that is, leave Debug and Release alone and create a build configuration per environment)

Command Line Build Statement

I'm building my Test configuration under the Debug solution configuration and it's definitely picking up the transformed Web.Debug.config file. There is no Web.Test.config file because Test is a "publish profile" not a build configuration.

cmd> msbuild websites.sln /t:Build /p:Configuration=Debug;Platform="Any CPU";DeployOnBuild=true;DeployTarget=Package;PublishProfile=Test;VisualStudioVersion=11.0

Maybe I'm doing something wrong here. I do feel like the Config/Platform are redundant, since I provide those in the Publish Profile dialog, as well. The Visual Studio Version was a surprise to me, but necessary to produce the zip package.

3
asp.netmsbuildweb.config-transform

3 Answers

2
votes

I would build a config per environment for consistency. However, if a configuration is not provided for a particular environment (i.e., web.Test.config), your published build will just use what was put in your original web.config file and not transform.

2
votes

If you build your websites sln from the command line you can provide the parameter OutputPath: e.g. 

msbuild websites.sln /p:OutputPath=c:\test

When this has run open c:\test and you will find a folder _PublishedWebsites with all your compiled sites in. No publish profiles required. Ah but how do i configure it without using msdeloy and publish profiles? You can create your own XDTs like the one for debug and release, web.config.staging add these files and set Build Action :content copy to output:Copy always

You can use an xdt transform tool like CCT to convert your web configs any time you like. (i.e. outside of Visual studio - on deploy or even redeploy) CTT is awesome BTW. Also to take it one step further you should make your XDT files templates and have properties for each env uat, prod etc..but that is another game.

2
votes

In the end, I did what Mitch started to suggest -- maintain a 1:1 relationship between solution/project configurations, publish profiles, and environments. The tooling works better if you give it everything it wants.

So, this should be a no-brainer

| Environment | Solution       | Publish  | Assembly       |
|             | Configuration  | Profile  | Configuration  |
============================================================
| Test        | Test           | Test     | Debug          |
| Staging     | Staging        | Staging  | Debug          |
| Prod        | Prod           | Prod     | Release        |

And I can specify the assembly build configuration in the publish profile (so that the production environment gets release optimizations). And, the configuration/platform properties disappear from the command line.

cmd> msbuild my.sln /t:Build /p:DeployOnBuild=true;DeployTarget=Package;PublishProfile=Staging;VisualStudioVersion=11.0

And everything ends up in a neat package folder

.\websites\somewebsite\obj\Staging\Package