Is it possible to pack a website with a publishing profile using msbuild and skip the web.config conversions?

Question

I have a solution for sites with three publishing profiles that we use to convert connection strings for each target environment:

• Test - localhost connections, no conversions, default values ​​are marked in
• Stage - VM Environment
• Production is the real deal

We also have some application settings that need to be converted for each environment. Thus, we used regular configuration-based conversions.

• Debugging - Conversion Settings for Stage
• Release Settings - transform for Production

This leaves us marinating when we try to pack a test profile. We pack it so that testers can deploy their systems from build artifacts instead of source code. But the test package picks up the Debug application settings.

Is there a way to tell msbuild about a website package using the Test profile, but skip the configuration conversion? Or do I need to restructure assembly configurations around the environment? (i.e. leave Debug and Release on your own and create build configuration for each environment)

Command Line Statement

I am creating my test configuration in the Debug solution configuration and, of course, Web.Debug.config converted Web.Debug.config file. There is no Web.Test.config file because Test is a "public profile" and not an assembly 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. I feel that Config / Platform are redundant since I provide them in the Publish Profile dialog box. The version of Visual Studio was a surprise to me, but it was necessary to create a zip package.

Answer 1

In the end, I did what Mitch started - keep a 1: 1 relationship between solution / project configurations, profile publishing, and environments. A tool works better if you give it everything that it wants.

So it should be no problem

 | 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 configuration of the assembly in the publication profile (so that the production environment receives release optimization). 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 it all ends in a neat package folder

 .\websites\somewebsite\obj\Staging\Package 

Answer 2

I would build a configuration for each environment for consistency. However, if the configuration is not intended for a specific environment (i.e. Web.Test.config), the published assembly will use only what was placed in your web.config source file, and not convert it.

Answer 3

If you create your sln websites from the command line, you can specify the OutputPath parameter: for example

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

When this starts, open c: \ test and you will find the _PublishedWebsites folder with all your compiled sites. No publishing profiles are required. Ah, but how do I configure it without using msdeloy and posting profiles? You can create your own XDTs, for example, for debugging and release, web.config.staging add these files and install Build Action: copy content to output: Always copy

You can use the xdt conversion tool, such as CCT , to convert your web configurations at any time convenient for you. (i.e. outside of Visual Studio - when deploying or even redeploying) CTT is awesome BTW. Also, to take it one step further, you must create your XDT file templates and have properties for each env uat, prod, etc., but this is another game.