NuGet task

  • 12 minutes to read
  • Contributors
    • elbatk
    • KathrynEE
    • Alex Homer
    • Steve Danielson
    • David Staheli

Version 2.* | Other versions

Azure Pipelines | Azure DevOps Server 2019 | TFS 2018

Use this task in a build or release pipeline to install and update NuGet package dependencies, or package and publish NuGet packages.

Note

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

If your code depends on NuGet packages, make sure to add this step before your Visual Studio Build step. Also make sure to clear the deprecated Restore NuGet Packages checkbox in that step.

Tip

Looking for help to get started? See the how-tos for restoring and publishing packages.

Tip

This version of the NuGet task uses NuGet 4.1.0 by default. To select a different version of NuGet, use the Tool Installer.

Note

Using or creating .NET Core or .NET Standard packages? Use the .NET Core task, which has full support for all package scenarios currently supported by dotnet, including restore, pack, and nuget push.

YAML snippet

# NuGet
# Restore, pack, or push NuGet packages, or run a NuGet command. Supports NuGet.org and authenticated feeds like Package Management and MyGet. Uses NuGet.exe and works with .NET Framework apps. For .NET Core and .NET Standard apps, use the .NET Core task.
- task: NuGetCommand@2
  inputs:
    #command: 'restore' # Options: restore, pack, push, custom
    #restoreSolution: '**/*.sln' # Required when command == Restore
    #feedsToUse: 'select' # Options: select, config
    #vstsFeed: # Required when feedsToUse == Select
    #includeNuGetOrg: true # Required when feedsToUse == Select
    #nugetConfigPath: # Required when feedsToUse == Config
    #externalFeedCredentials: # Optional
    #noCache: false 
    #disableParallelProcessing: false 
    restoreDirectory: 
    #verbosityRestore: 'Detailed' # Options: quiet, normal, detailed
    #packagesToPush: '$(Build.ArtifactStagingDirectory)/**/*.nupkg;!$(Build.ArtifactStagingDirectory)/**/*.symbols.nupkg' # Required when command == Push
    #nuGetFeedType: 'internal' # Required when command == Push# Options: internal, external
    #publishVstsFeed: # Required when command == Push && NuGetFeedType == Internal
    #publishPackageMetadata: true # Optional
    #allowPackageConflicts: # Optional
    #publishFeedCredentials: # Required when command == Push && NuGetFeedType == External
    #verbosityPush: 'Detailed' # Options: quiet, normal, detailed
    #packagesToPack: '**/*.csproj' # Required when command == Pack
    #configuration: '$(BuildConfiguration)' # Optional
    #packDestination: '$(Build.ArtifactStagingDirectory)' # Optional
    #versioningScheme: 'off' # Options: off, byPrereleaseNumber, byEnvVar, byBuildNumber
    #includeReferencedProjects: false # Optional
    #versionEnvVar: # Required when versioningScheme == ByEnvVar
    #majorVersion: '1' # Required when versioningScheme == ByPrereleaseNumber
    #minorVersion: '0' # Required when versioningScheme == ByPrereleaseNumber
    #patchVersion: '0' # Required when versioningScheme == ByPrereleaseNumber
    #packTimezone: 'utc' # Required when versioningScheme == ByPrereleaseNumber# Options: utc, local
    #includeSymbols: false # Optional
    #toolPackage: # Optional
    #buildProperties: # Optional
    #basePath: # Optional
    #verbosityPack: 'Detailed' # Options: quiet, normal, detailed
    #arguments: # Required when command == Custom

Versioning schemes

For byPrereleaseNumber, the version will be set to whatever you choose for major, minor, and patch, plus the date and time in the format yyyymmdd-hhmmss.

For byEnvVar, the version will be set as whatever environment variable, e.g. MyVersion (no $, just the environment variable name), you provide. Make sure the environment variable is set to a proper SemVer e.g. 1.2.3 or 1.2.3-beta1.

For byBuildNumber, the version will be set to the build number, ensure that your build number is a proper SemVer e.g. 1.0.$(Rev:r). If you select byBuildNumber, the task will extract a dotted version, 1.2.3.4 and use only that, dropping any label. To use the build number as is, you should use byEnvVar as described above, and set the environment variable to BUILD_BUILDNUMBER.

Restore NuGet packages

Demands

None

Arguments

Argument Description
Path to solution, packages.config, or project.json Copy the Solution argument in your Visual Studio Build 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 NuGet.org and/or one Azure Artifacts/Package Management feed in the same organization/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 organization/collection can be used to inject credentials you've provided as a NuGet service connection into your NuGet.config as the build runs.
  • Azure Artifacts users: see the walkthrough for help using packages from feeds in multiple Azure DevOps organizations.
Advanced
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

Examples

Install NuGet dependencies

You're building a Visual Studio solution that depends on a NuGet feed.

`-- ConsoleApplication1
    |-- ConsoleApplication1.sln
    |-- NuGet.config
    `-- ConsoleApplication1
        |-- ConsoleApplication1.csproj
Build steps
Package: NuGet
Package: NuGet		 Install your NuGet package dependencies.
  • Path to solution, packages.config, or project.json: **/*.sln
  • Feeds to use: Feeds in my NuGet.config
  • Path to NuGet.config: ConsoleApplication1/NuGet.config
Build: Visual Studio Build
Build: Visual Studio Build		 Build your solution.
  • Solution: **\*.sln
  • Restore NuGet Packages: (Important) Make sure this option is cleared.

Pack NuGet packages

Demands

None

Arguments

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 versioning schemes for version options). 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.
Advanced
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

Demands

None

Arguments

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 file matching patterns to publish multiple packages. Note that these patterns were updated in version 2 of the NuGet task; if you have a pattern that contains -:, use ! instead.
  • 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 organization/collection publishes to an Azure Artifacts/Package Management feed in the same organization/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.
  • External NuGet server (including other organizations/collections) publishes to an external server such as NuGet, MyGet, or an Azure Artifacts/Package Management feed in another Azure DevOps organization or TFS collection. After you select this option, you create and select a NuGet service connection.
Advanced
Verbosity Specifies the amount of detail displayed in the output.
Control options

Publishing symbols

When you push packages to an Azure Artifacts/Package Management feed, you can also publish symbols using the Index Sources & Publish Symbols task.

Publishing packages to TFS with IIS Basic authentication enabled

This task is unable to publish NuGet packages to a TFS Package Management feed that is running on a TFS server with IIS Basic authentication enabled. See here for more details.

Custom NuGet command

YAML snippet

# NuGet Command
# Deprecated: use the “NuGet” task instead. It works with the new Tool Installer framework so you can easily use new versions of NuGet without waiting for a task update, provides better support for authenticated feeds outside this organization/collection, and uses NuGet 4 by default.
- task: NuGet@0
  inputs:
    command: 
    arguments:

Arguments

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

End-to-end example

You want to package and publish some projects in a C# class library to your Azure Artifacts feed.

You want to package and publish some projects in a C# class library to your TFS Package Management feed.

`-- Message
    |-- Message.sln
    `-- ShortGreeting
        |-- ShortGreeting.csproj
        |-- Class1.cs
        `-- Properties
            |-- AssemblyInfo.cs
    `-- LongGreeting
        |-- LongGreeting.csproj
        |-- Class1.cs
        `-- Properties
            |-- AssemblyInfo.cs

Prepare

AssemblyInfo.cs

Make sure your AssemblyInfo.cs files contain the information you want shown in your packages. For example, AssemblyCompanyAttribute will be shown as the author, and AssemblyDescriptionAttribute will be shown as the description.

Variables tab

Name Value
$(BuildConfiguration) release
$(BuildPlatform) any cpu

Options

Setting Value
Build number format $(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)

Publish to Azure Artifacts

Publish to a TFS feed

  1. Make sure you've prepared the build as described above.
  2. If you haven't already, create a feed.
  3. Add the following build steps:
Package: NuGet
Package: NuGet		 Install your NuGet package dependencies.
  • Path to solution, packages.config, or project.json: **/*.sln
  • Feeds to use: Feeds I select here
  • Use packages from NuGet.org: Checked
Build: Visual Studio Build
Build: Visual Studio Build

Build your solution.

  • Solution: **\*.sln
  • Platform: $(BuildPlatform)
  • Configuration: $(BuildConfiguration)
Package: NuGet
Package: NuGet

Package your projects.

  • Command: pack
  • Path to csproj or nuspec file(s) to pack: **/*.csproj
  • Configuration to Package: Release
  • Package Folder: $(Build.ArtifactStagingDirectory)
  • Pack options > Automatic package versioning: Use the build number
Package: NuGet
Package: NuGet

Publish your packages.

  • Command: push
  • Path to NuGet package(s) to publish: $(Build.ArtifactStagingDirectory)
  • Target feed location: This organization/collection
  • Target feed: Select your feed

Option 2: publish to NuGet.org

  1. Make sure you've prepared the build as described above.
  2. If you haven't already, register with NuGet.org.
  3. Use the steps in the previous section, but substitute the final step for the step shown here.
Package: NuGet
Package: NuGet

Publish your packages to NuGet.org.

  • Command: push
  • Path to NuGet package(s) to publish: $(Build.ArtifactStagingDirectory)
  • Target feed location: External NuGet server
  • NuGet server: Create a new NuGet service connection with your NuGet.org ApiKey and select it here

Task versions

Task: NuGet (formerly NuGet Restore at 1.*, NuGet Installer at 0.*)

Task version Azure Pipelines TFS
2.* Available Appeared in 2018
1.* Deprecated but available Appeared in 2017 Update 2, deprecated in 2018
0.* Deprecated but available Appeared in 2017, deprecated in 2017 Update 2

Task: NuGet Packager

Task version Azure Pipelines TFS
0.* Deprecated but available Available in TFS < 2018, deprecated in TFS >= 2018

Task: NuGet Publisher

Task version Azure Pipelines TFS
0.* Deprecated but available Available in TFS < 2018, deprecated in TFS >= 2018

Task: NuGet Command

Task version Azure Pipelines TFS
0.* Deprecated but available Available in TFS < 2017 Update 2, deprecated in TFS >= 2018

Open source

These tasks are open source on GitHub. Feedback and contributions are welcome.

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 an Azure Artifacts 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 Azure Artifacts?

Package Management in Azure Artifacts and TFS

Where can I learn more about NuGet?

NuGet Docs Overview

NuGet Create Packaging and publishing

NuGet Consume Setting up a solution to get dependencies

What other kinds of apps can I build?

Build your app

What other kinds of build tasks are available?

Specify your build tasks

How do we protect our codebase from build breaks?

How do I modify other parts of my build pipeline?

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

If you're using Azure Pipelines, you might need more parallel jobs. See Parallel jobs in Azure Pipelines.

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

View the change history of your build pipeline

Do I need an agent?

You need at least one agent to run your build or release. Get an agent for Linux, macOS, or Windows.

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.