How to build multiple configurations in a single VSTS build

Problem:

When I try to build debug and release at the same time I get the following error:

The specified solution configuration "release, debug|any cpu" is invalid. Please specify a valid solution configuration using the Configuration and Platform properties (e.g. MSBuild.exe Solution.sln /p:Configuration=Debug /p:Platform="Any CPU") or leave those properties blank to use the default solution configuration.

Solution:

Enable the Multi-configuration option.

image

Explanation:

By default the Multi-configuration option is disabled. To build multiple configurations at once, you actually have to do more than just check the box. First you need to update the BuildConfiguration variable to a comma-delimited string of configurations.

  1. Select the build
  2. Click the Edit link
  3. Click the Variables tab
    Field Value
    BuildConfiguration release,debug

    image

With the build configuration updated, you can now enable the Multi-configuration option.

  1. Click the Options tab
  2. Check the Multi-configuration checkbox
    Field Value
    Multipliers BuildConfiguration
  3. Click Save

Now when you queue a new build, both configurations will build.

image

Comments (11) -

  • Thank you! Your post here helped me after about a week of testing and searching for the correct way to build multiple configurations.
  • Donovan, is it possible to build multiple configurations in a single queue?
    For now another builds wedged between each configuration and Multi-configuration build takes a long time.
  • Hello, Donovan!
    Is it possible to make Multi-configuration build in a single queue?
    For now another builds wedged between building each configuration and Multi-configuration build takes a long time.
    • If you only have a single agent in your queue each build will happen one after the other.  If your builds to happen at the same time you must have multiple agents in your queue.  
  • Quick question. If I have a release and debug version of a website, how do you stop it from building into the same zip, etc?
    • Change MSBuild Arguments from:
      /peployOnBuild=true /p:WebPublishMethod=Package /packageAsSingleFile=true /p:SkipInvalidConfigurations=true /packageLocation="$(build.artifactstagingdirectory)\\"

      To
      /peployOnBuild=true /p:WebPublishMethod=Package /packageAsSingleFile=true /p:SkipInvalidConfigurations=true /packageLocation="$(build.artifactstagingdirectory)\\$(BuildConfiguration)\\"

      By adding $(BuildConfiguration) each config will get a different zip.
  • Hey Donovan,

    Can CD release definitions with Multi-configuration builds?
    I have configured this multi-configuration build + CD Release definition for some 4-5 configurations in my current project. However the challenge that I have is if for eg. my environments are dev, bvt, st, sit in the same order in same build and release definition to deploy one after other, and If I need to build only DEV and ST, then the Release will get created and deployed on DEV alright. But after deploying on dev it will look for BVT artifact which it won't find so it will fail the release deployment on BVT and it won't go further and deploy on ST.
    Do you have any ideas for this that the release should somehow figure out that the the artifact is available for specific configurations and should deploy only to those environments?
    • I would like to better understand why you are not deploying the same bits in each environment. What is different in each config?
      • That is because each environment configuration file has urls etc for that specific environment in Azure. Our environment corresponds to a Resource group in Azure.
        • I would recommend you use tokenization to config changes between environments. That way you deploy the exact build in every environment and have release management update the configuration values as part of the release. This extension has the tasks you need marketplace.visualstudio.com/items
          This will help you adhere to DevOps best practices. You want to deploy the same build in every environment and not a build per environment.

Add comment

Loading