MSBuild task
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.
Demands
msbuild
Azure Pipelines: If your team uses Visual Studio 2017 and you want to use the Microsoft-hosted agents, make sure you select as your default pool the Hosted VS2017. See Microsoft-hosted agents.
Arguments
Argument | Description |
---|---|
solution Project |
(Required) If you want to build a single project, click the ... button and select the project. If you want to build multiple projects, specify search criteria. You can use a single-folder wildcard ( Make sure the projects you specify are downloaded by this build pipeline. On the Repository tab:
Tip: If you are building a solution, we recommend you use the Visual Studio build task instead of the MSBuild task. Default value: **/*.sln |
msbuildLocationMethod MSBuild |
(Optional) Default value: version |
msbuildVersion MSBuild Version |
(Optional) If the preferred version cannot be found, the latest version found will be used instead. On an macOS agent, xbuild (Mono) will be used if version is lower than 15.0 Default value: latest |
msbuildArchitecture MSBuild Architecture |
(Optional) Optionally supply the architecture (x86, x64) of MSBuild to run Default value: x86 |
msbuildLocation Path to MSBuild |
(Optional) Optionally supply the path to MSBuild |
platform Platform |
(Optional) Specify the platform you want to build such as Tips:
|
configuration Configuration |
(Optional) Specify the configuration you want to build such as Tip: Declare a build variable such as |
msbuildArguments MSBuild Arguments |
(Optional) Additional arguments passed to MSBuild (on Windows) and xbuild (on macOS) |
clean Clean |
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 See, repo options Default value: false |
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 |
Advanced options
Argument | Description |
---|---|
logProjectEvents Record Project Details |
Optionally record timeline details for each project (Windows only) Default value: false |
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 |
Task 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 command-line reference
How do I build multiple configurations for multiple platforms?
-
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 -
On the Options tab, select MultiConfiguration and specify the Multipliers, separated by commas. For example:
BuildConfiguration, BuildPlatform
Select Parallel if you want to distribute the jobs (one for each combination of values) to multiple agents in parallel if they are available.
-
On the Build tab, select this step and specify the Platform and Configuration arguments. For example:
- Platform:
$(BuildPlatform)
- Configuration:
$(BuildConfiguration)
- Platform:
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.
My NuGet push task is failing with the following error: "Error: unable to get local issuer certificate". How can I fix this?
This can be fixed by adding a trusted root certificate. You can either add the NODE_EXTRA_CA_CERTS=file
environment variable to your build agent, or you can add the NODE.EXTRA.CA.CERTS=file
task variable in your pipeline. See Node.js documentation for more details about this variable. See Set variables in a pipeline for instructions on setting a variable in your pipeline.
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.
Troubleshooting
This section provides troubleshooting tips for common issues that a user might encounter when using the MSBuild task.
Build failed with the following error: An internal failure occurred while running MSBuild
Possible causes
- Change in the MSBuild version.
- Issues with a third-party extension.
- New updates to Visual Studio that can cause missing assemblies on the build agent.
- Moved or deleted some of the necessary NuGet packages.
Troubleshooting suggestions
- Run the pipeline with diagnostics to retrieve detailed logs
- Try to reproduce the error locally
- What else can I do?
Run the pipeline with diagnostics to retrieve detailed logs
One of the available options to diagnose the issue is to take a look at the generated logs. You can view your pipeline logs by selecting the appropriate task and job in your pipeline run summary.
To get the logs of your pipeline execution Get logs to diagnose problems
You can also setup and download a customized verbose log to assist with your troubleshooting:
In addition to the pipeline diagnostic logs, you can also check these other types of logs that contain more information to help you debug and solve the problem:
- Worker diagnostic logs
- Agent diagnostic logs
- Other logs (Environment and capabilities)
Try to reproduce the error locally
If you are using a hosted build agent, you might want to try to reproduce the error locally. This will help you to narrow down whether the failure is the result of the build agent or the build task.
Run the same MSBuild command on your local machine using the same arguments. Check out MSBuild command for reference
Tip
If you can reproduce the problem on your local machine, then your next step is to investigate the MSBuild issue.
For more information on Microsoft hosted agents
To setup your own self-hosted agent and run the build jobs:
What else can I do?
At the bottom of this page, check out the GitHub issues in the Open
and Closed
tabs to see if there is a similar issue that has been resolved previously by our team.
Some of the MSBuild errors are caused by a change in Visual Studio so you can search on Visual Studio Developer Community to see if this issue has been reported. We also welcome your questions, suggestions, and feedback.