Visual Studio Build task

Azure Pipelines | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015

Note

In Microsoft Team Foundation Server (TFS) 2018 and previous versions, build and release pipelines are called definitions, runs are called builds, service connections are called service endpoints, stages are called environments, and jobs are called phases.

Use this task to build with MSBuild and set the Visual Studio version property.

Demands

msbuild, visualstudio

Azure Pipelines: If your team wants to use Visual Studio 2017 with the Microsoft-hosted agents, select Hosted VS2017 as your default build pool. See Microsoft-hosted agents.

YAML snippet

# Visual Studio build
# Build with MSBuild and set the Visual Studio version property
- task: VSBuild@1
  inputs:
    #solution: '**\*.sln' 
    #vsVersion: 'latest' # Optional. Options: latest, 16.0, 15.0, 14.0, 12.0, 11.0
    #msbuildArgs: # Optional
    #platform: # Optional
    #configuration: # Optional
    #clean: false # Optional
    #maximumCpuCount: false # Optional
    #restoreNugetPackages: false # Optional
    #msbuildArchitecture: 'x86' # Optional. Options: x86, x64
    #logProjectEvents: true # Optional
    #createLogFile: false # Optional
    #logFileVerbosity: 'normal' # Optional. Options: quiet, minimal, normal, detailed, diagnostic

Arguments

Argument Description
solution
Solution

(Required) If you want to build a single solution, click the ... button and select the solution.

If you want to build multiple solutions, specify search criteria. You can use a single-folder wildcard (`*`) and recursive wildcards (`**`). For example, `**.sln` searches for all .sln files in all subdirectories.

Make sure the solutions you specify are downloaded by this build pipeline. On the Repository tab:

  • If you use TFVC, make sure that the solution is a child of one of the mappings on the Repository tab.
  • If you use Git, make sure that the project or solution is in your Git repo, and in a branch that you're building.

Tips:

  • You can also build MSBuild project (.*proj) files.
  • If you are building a customized MSBuild project file, we recommend you use the MSBuild task instead of the Visual Studio Build task.

Default value: **\*.sln
vsVersion
Visual Studio Version

To avoid problems overall, you must make sure this value matches the version of Visual Studio used to create your solution.

The value you select here adds the /p:VisualStudioVersion={numeric_visual_studio_version} argument to the MSBuild command run by the build. For example, if you select Visual Studio 2015, /p:VisualStudioVersion=14.0 is added to the MSBuild command.

Azure Pipelines:If your team wants to use Visual Studio 2017 with the Microsoft-hosted agents, select Hosted VS2017 as your default build pool. See Microsoft-hosted agents.


Default value: latest
msbuildArgs
MSBuild Arguments
(Optional) You can pass additional arguments to MSBuild. For syntax, see MSBuild Command-Line Reference.
platform
Platform

(Optional) Specify the platform you want to build such as Win32, x86, x64 or any cpu.

Tips:

  • If you are targeting an MSBuild project (.*proj) file instead of a solution, specify AnyCPU (no whitespace).
  • Declare a build variable such as BuildPlatform on the Variables tab (selecting Allow at Queue Time) and reference it here as $(BuildPlatform). This way you can modify the platform when you queue the build and enable building multiple configurations.
configuration
Configuration

(Optional) Specify the configuration you want to build such as debug or release.

Tip: Declare a build variable such as BuildConfiguration on the Variables tab (selecting Allow at Queue Time) and reference it here as $(BuildConfiguration). This way you can modify the platform when you queue the build and enable building multiple configurations.

clean
Clean

(Optional) Set to False if you want to make this an incremental build. This setting might reduce your build time, especially if your codebase is large. This option has no practical effect unless you also set Clean repository to False.

Set to True if you want to rebuild all the code in the code projects. This is equivalent to the MSBuild /target:clean argument.

Advanced
maximumCpuCount
Build in Parallel
(Optional) If your MSBuild target configuration is compatible with building in parallel, you can optionally check this input to pass the /m switch to MSBuild (Windows only). If your target configuration is not compatible with building in parallel, checking this option may cause your build to result in file-in-use errors, or intermittent or inconsistent build failures.
Default value: false
restoreNugetPackages
Restore NuGet Packages
(Important) This option is deprecated. Make sure to clear this checkbox and instead use the NuGet Installer build task.
Default value: false
msbuildArchitecture
MSBuild Architecture

Optionally supply the architecture (x86, x64) of MSBuild to run

Tip: Because Visual Studio runs as a 32-bit application, you could experience problems when your build is processed by a build agent that is running the 64-bit version of Team Foundation Build Service. By selecting MSBuild x86, you might resolve these kinds of problems.


Default value: x86
logProjectEvents
Record Project Details
Optionally record timeline details for each project
Default value: true
createLogFile
Create Log File
Optionally create a log file (Windows only)
Default value: false
logFileVerbosity
Log File Verbosity
Optional log file verbosity
Default value: normal
Control options

Open source

This task is open source on GitHub. Feedback and contributions are welcome.

FAQ

Should I use the Visual Studio Build task or the MSBuild task?

If you are building a solution, in most cases you should use the Visual Studio Build task. This task automatically:

  • Sets the /p:VisualStudioVersion property for you. This forces MSBuild to use a particular set of targets that increase the likelihood of a successful build.

  • Specifies the MSBuild version argument.

In some cases you might need to use the MSBuild task. For example, you should use it if you are building code projects apart from a solution.

Where can I learn more about MSBuild?

MSBuild task

MSBuild reference

MSBuild command-line reference

How do I build multiple configurations for multiple platforms?

  1. On the Variables tab, make sure you've got variables defined for your configurations and platforms. To specify multiple values, separate them with commas.

    For example, for a .NET app you could specify:

    Name Value
    BuildConfiguration debug, release
    BuildPlatform any cpu

    For example, for a C++ app you could specify:

    Name Value
    BuildConfiguration debug, release
    BuildPlatform x86, x64
  2. On the Options tab select Parallel if you want to distribute the jobs (one for each combination of values) to multiple agents in parallel if they are available.

  3. On the Build tab, select this step and specify the Platform and Configuration arguments. For example:

    • Platform: $(BuildPlatform)
    • Configuration: $(BuildConfiguration)
  4. Under the agent job of the assigned task, on the Parallelism tab, select Multi-configuration and specify the Multipliers separated by commas. For example: BuildConfiguration, BuildPlatform

Can I build TFSBuild.proj files?

You cannot build TFSBuild.proj files. These kinds of files are generated by TFS 2005 and 2008. These files contain tasks and targets are supported only using XAML builds.

Do I need an agent?

You need at least one agent to run your build or release.

I'm having problems. How can I troubleshoot them?

See Troubleshoot Build and Release.

I can't select a default agent pool and I can't queue my build or release. How do I fix this?

See Agent pools.

I use TFS on-premises and I don't see some of these features. Why not?

Some of these features are available only on Azure Pipelines and not yet available on-premises. Some features are available on-premises if you have upgraded to the latest version of TFS.