Choose Nuget Packager version in Visual Studio Team Services build step

Question

Why I cannot choose nuget version in build step configuration in Visual Studio Team Services? It seems that for every other nuget build step (installer, publisher) I can choose between 3.3.0 and 3.5.0, but for this one I'm forced to download nuget.exe, check it into source control and provide a path to the exe.

Since nuget 3.3.0 cannot deal with making packages directly from project.json it would make so much sense to be able to choose the version in this step.

Answer 1

Yes, the nuget version is defined in NuGet Publisher task, but not in NuGet Packager task so far. If you need to choose nuget version, you can develop your own task similar with NuGet Packager . All VSTS tasks code are here for your reference.

Option2: you can add the nuget version you wan to use in source control, and add the path in NuGet Packager task. Details you can refer here .

Answer 2

I had this exact same issue and received a very helpful response from a MS support technician. This downloads 3.5.0 to a temp location if it doesn't already exist, so avoids having to have nuget.exe in your source control system.

1) Add Task of type Powershell script and place it above your Nuget Packager step.
2) Set Type to "Inline Script"
3) Replace default Inline Script value with this:

$v = '3.5.0'
$u = "https://dist.nuget.org/win-x86-commandline/v$v/NuGet.exe"
$p = Join-Path ([IO.Path]::GetTempPath()) "NuGet-$v.exe"
Write-Host "##vso[task.setvariable variable=downloadedNuGetExe]$p"
if (Test-Path $p) { return }
Invoke-WebRequest $u -OutFile $p

4) In Nuget Packager build step, set Path to Nuget.exe value to the variable we just set:

$(downloadedNuGetExe)

Hope this helps, and thanks to the MS support technician, Aruna, for this solution!

Answer 3

[Update 11/29/2017 with new feature information]

The NuGet Tool Installer task is the preferred way to manage the version of NuGet used in your build. See this blog post for more info.

Answer 4

I cannot think of any good reason and looking at the repository for the tasks they were created by separate developers, maybe a comms mix-up, who knows? :)

You can see by looking at the task.json for the Packager here and the Publisher here that it just wasn't implemented for the Packager - it's here on L91 of the Publisher.

Issue #3636 was logged for it, once fixed this will be available on VSTS shortly after.