Build: .NET Core

VSTS | TFS 2018 | 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

Demands

None

YAML snippet

# .NET Core
# Restore NuGet packages.
- task: DotNetCoreCLI@2
  inputs:
    command: 'restore'
    projects: '**/*.csproj'
    #verbosityRestore: 'detailed' # Options: quiet, minimal, normal, detailed, diagnostic

Arguments

ArgumentDescription
Command(Required) The dotnet command to run. Select 'Custom' to add arguments or use a command not listed here.
Path to project(s)(Optional) The path to the csproj file(s) to use. You can use wildcards (e.g. **/.csproj for all .csproj files in all subfolders).
Verbosity(Required) Specifies the amount of detail displayed in the output.
Control options

Pack NuGet packages

Demands

None

YAML snippet

# .NET Core
# Pack NuGet packages.
- task: DotNetCoreCLI@2
  inputs:
    command: 'pack'
    configuration: 'release'
    #packagesToPack: '**/*.csproj' # Required when command == pack
    #packDirectory: '$(build.artifactStagingDirectory)' # Optional
    #nobuild: false # Optional
    #versioningScheme: 'off' # Options: off, byPrereleaseNumber, byEnvVar, byBuildNumber
    #versionEnvVar: # Required when versioningScheme == byEnvVar
    #majorVersion: '1' # Required when versioningScheme == byPrereleaseNumber
    #minorVersion: '0' # Required when versioningScheme == byPrereleaseNumber
    #patchVersion: '0' # Required when versioningScheme == byPrereleaseNumber
    #buildProperties: # Optional
    #verbosityPack: 'detailed' # Options: quiet, minimal, normal, detailed, diagnostic

Arguments

ArgumentDescription
Command(Required) The dotnet command to run. Select 'Custom' to add arguments or use a command not listed here.
Configuration to Package(Optional) When using a csproj file this specifies the configuration to package
Package Folder(Optional) Folder where packages will be created. If empty, packages will be created alongside the csproj file.
Do not build(Optional) Don't build the project before packing. Corresponds to the --no-build command line parameter.
Automatic package versioning(Required) Cannot be used with include referenced projects. If you choose 'Use the date and time', this will generate a SemVer-compliant version formatted as X.Y.Z-ci-datetime where you choose X, Y, and Z. If you choose 'Use an environment variable', you must select an environment variable and ensure it contains the version number you want to use. If you choose 'Use the build number', this will use the build number to version your package. Note: Under Options set the build number format to be '$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)'.
Environment variable(Required) Enter the variable name without $, $env, or %.
Major(Required) The 'X' in version X.Y.Z
Minor(Required) The 'Y' in version X.Y.Z
Patch(Required) The 'Z' in version X.Y.Z
Additional build properties(Optional) Specifies a list of token = value pairs, separated by semicolons, where each occurrence of $token$ in the .nuspec file will be replaced with the given value. Values can be strings in quotation marks.
Verbosity(Required) Specifies the amount of detail displayed in the output.
Control options

Push NuGet packages

Demands

None

YAML snippet

# .NET Core
# Push NuGet packages.
- task: DotNetCoreCLI@2
  inputs:
    command: 'push'
    #nuGetFeedType: 'internal' # Required when command == push. Options: internal, external
    #packagesToPush: '$(build.artifactStagingDirectory)/*.nupkg' # Required when command == push
    #publishVstsFeed: # Required when command == push && NuGetFeedType == internal
    #publishFeedCredentials: # Required when command == push && NuGetFeedType == external

Arguments

ArgumentDescription
Command(Required) The dotnet command to run. Select 'Custom' to add arguments or use a command not listed here.
Target feed location(Required) Use 'internal' for this account/collection. Use 'external' for an external NuGet server (including other accounts/collections).
Path to NuGet package(s) to publish(Required) The pattern to match or path to nupkg files to be uploaded. Multiple patterns can be separated by a semicolon, and you can make a pattern negative by prefixing it with '-:'. Example: **\*.nupkg;-:**\*.Tests.nupkg
Target feed(Required) Select a feed hosted in this account. You must have Package Management installed and licensed to select a feed here.
NuGet server(Required) The NuGet service endpoint that contains the external NuGet server’s credentials.
Control options

Custom NuGet command

YAML snippet

# .NET Core
# Custom NuGet command.
- task: DotNetCoreCLI@2
  inputs:
    command: custom
    projects: '**/.csproj'
    custom: 'Enter your custom NuGet command here'
    arguments: '--configuration release --output $(build.artifactStagingDirectory)'

Arguments

ArgumentDescription
Command(Required) The dotnet command to run. Select 'Custom' to add arguments or use a command not listed here.
Path to project(s)(Optional) The path to the csproj file(s) to use. You can use wildcards (e.g. **/.csproj for all .csproj files in all subfolders).
Custom command(Required) The command to pass to dotnet.exe for execution.
Arguments(Optional) Arguments to the selected command. For example, build configuration, output folder, runtime. The arguments depend on the command selected.
Control options

Q & A

Why is my build or publish step failing to restore packages?

Most dotnet commands, including build and publish, include an implicit restore step. This will fail against authenticated feeds, even if you ran a successful dotnet restore in an earlier step, because the earlier step will have cleaned up the credentials it used.

To fix this issue, add the --no-restore flag to the Arguments textbox.

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 Agent pools and queues.

I use TFS 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.