Build: .NET Core

VSTS | TFS 2017

Build, test, and release .NET Core and .NET Standard projects and create .NET Core and .NET Standard NuGet packages using the dotnet command-line tool.

If your .NET Core or .NET Standard build depends on NuGet packages, make sure to add two copies of this step: one with the restore command and one with the build command.

Restore NuGet packages




Argument Description
Path to project(s) Copy the Project(s) argument in your build command step and paste it here, or create a link using the Link button in the information panel.
Feeds and authentication
Feeds to use Feed(s) I select here:
  • Select this option to use and/or one Package Management feed in the same account/collection as the build.
Feeds in my NuGet.config:
  • Select this option to use feeds specified in a NuGet.config file you've checked into source control.
  • Credentials for feeds outside this account/collection can be used to inject credentials you've provided as a NuGet service endpoint into your NuGet.config as the build runs.
Disable local cache Prevents NuGet from using packages from local machine caches.
Destination directory Specifies the folder in which packages are installed. If no folder is specified, packages are restored into a packages/ folder alongside the selected solution, packages.config, or project.json.
Verbosity Specifies the amount of detail displayed in the output.
Control options

Pack NuGet packages




Argument Description
Path to csproj or nuspec file(s) to pack Specify .csproj files (for example, **\*.csproj) for simple projects. In this case:
  • The packager compiles the .csproj files for packaging.
  • You must specify Configuration to Package (see below).
  • You do not have to check in a .nuspec file. If you do check one in, the packager honors its settings and replaces tokens such as $id$ and $description$.
Specify .nuspec files (for example, **\*.nuspec) for more complex projects, such as multi-platform scenarios in which you need to compile and package in separate steps. In this case:
  • The packager does not compile the .csproj files for packaging.
  • Each project is packaged only if it has a .nuspec file checked in.
  • The packager does not replace tokens in the .nuspec file (except the <version/> element, see Use build number to version package, below). You must supply values for elements such as <id/> and <description/>. The most common way to do this is to hardcode the values in the .nuspec file.
To package a single file, click the ... button and select the file. To package multiple files, use file matching patterns. Note that these patterns were updated in version 2 of the NuGet task; if you have a pattern that contains -:, use ! instead.
Configuration to package If you are packaging a .csproj file, you must specify a configuration that you are building and that you want to package. For example: Release or $(BuildConfiguration)
Package folder (Optional) Specify the folder where you want to put the packages. You can use a variable such as $(Build.ArtifactStagingDirectory) If you leave it empty, the package will be created in the root of your source tree.
Pack options
Automatic package versioning This blog post provides an overview of the automatic package versioning available here.
Additional build properties Semicolon delimited list of properties used to build the package. For example, you could replace <description>$description$</description> in the .nuspec file this way: Description="This is a great package" Using this argument is equivalent to supplying properties from nuget pack with the -Properties option.
Verbosity Specifies the amount of detail displayed in the output.
Control options

Push NuGet packages




Argument Description
Path to NuGet package(s) to publish Specify the packages you want to publish.
  • Default value: $(Build.ArtifactStagingDirectory)/*.nupkg
  • To publish a single package, click the ... button and select the file.
  • Use single-folder wildcards (*) and recursive wildcards (**) to publish multiple packages.
  • Use variables to specify directories. For example, if you specified $(Build.ArtifactStagingDirectory)\ as the package folder in the pack step above, you could specify $(Build.ArtifactStagingDirectory)\**\*.nupkg here.
Target feed location
  • This account/collection publishes to a Package Management feed in the same account/collection as the build. After you select this option, select the target feed from the dropdown.
    • "Allow duplicates to be skipped" allows you to continually publish a set of packages and only change the version number of the subset of packages that changed. It allows the task to report success even if some of your packages are rejected with 409 Conflict errors.
      This option is currently only available on VSTS.
  • External NuGet server (including other accounts/collections) publishes to an external server such as NuGet, MyGet, or a Package Management feed in another VSTS account or TFS collection. After you select this option, you create and select a NuGet service endpoint.
Verbosity Specifies the amount of detail displayed in the output.
Control options

Custom NuGet command


Argument Description
Command and arguments NuGet command and arguments you want to pass as your custom command.

Q & A

Why should I check in a NuGet.Config?

Checking a NuGet.Config into source control ensures that a key piece of information needed to build your project—the location of its packages—is available to every developer that checks out your code.

However, for situations where a team of developers works on a large range of projects, it's also possible to add a VSTS feed to the global NuGet.Config on each developer's machine. In these situations, using the "Feeds I select here" option in the NuGet task replicates this configuration.

Where can I learn about VSTS package management?

Package Management in VSTS and TFS

Where can I learn more about NuGet?

NuGet Docs Overview

NuGet Create Packaging and publishing

NuGet Consume Seting up a solution to get dependencies

What other kinds of apps can I build?

Build your app

What other kinds of build steps are available?

Specify your build steps

How do we protect our codebase from build breaks?

How do I modify other parts of my build definition?

I selected parallel multi-configuration, but only one build is running at a time.

If you're using VSTS, you might need more concurrent pipelines. See Concurrent build and release pipelines in VSTS.

How do I see what has changed in my build definition?

View the change history of your build definition

Do I need an agent?

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

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

See queues.

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

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