Honestly, VSTS private NuGet feeds will be a most blogged topic in this blog! I’ve already mentioned them at least twice. Here goes another post:

This time I’m building in VSTS Core application and the build literally goes:

  • dotnet restore
  • dotnet build
  • dotnet test
  • dotnet publish

And this worked really well for the basic application – I had it set up in minutes and got the resuilt I was looking for.

But during the life of the application I needed NuGet packages from my private feed and dotnet restore had no idea about my private feeds.

Even if supplied with nuget.config file I was getting 401 Unauthenticated – this is because I was not keeping my password(token) in this file.

Solution was to add this feed globally on the agent for every build. And this turned out to be easier than I thought.

In your build add a new task called Nuget Command:

When you configure this task give sources as Command parameter. And for arguments put this:

add -Name MyFeedName -Source https://MyProject.pkgs.visualstudio.com/_packaging/MyFeedName/nuget/v3/index.json -username myUsername@MyTeamName.onmicrosoft.com -password $(System.AccessToken)

My build task looks like this:

Replace the names accordingly. This adds a NuGet source to the agent. This $(System.AccessToken) is getting build variable that contains an access token – it is generated for every build you run, so no need to keep it around in your build script or nuget.config.

To make the token available you need change the toggle in build Options: Change Allow scripts to access OAuth Token to Enabled:

This way when you run dotnet restore your private feed will be available and it will use OAuth token that authenticates with the private package feed.

  • SchmidtTroy

    Miracle I found this blog. We are on a similar development path using Cake Build, VSTS, .NET Core, XUnit, and React. Figuring out how to make all the things play along nicely has been an experience. I just got to pushing NuGet packages to the local Package Management and needed them to be found when I came across this after several hours.

    Would love if you have any other advice, tips, etc on using Cake Build with VSTS Build definitions. I have it building pretty well and pushing XUnit and Jest test results and OpenCover / Junit coverage reports without using VS official testing framework and tools.

    • To be honest, one of my plans is to get rid of Cake for VSTS. Cake plays nicely with GitHub and AppVeyor builds. But on VSTS it was only adding complications and pain points.Tests with tests results are executed on VSTS via their step and configured in something like half-minute. It took me a while to get the tests results to show up. One of the obscure bugs in Cake-VSTS integration consumed 3 days of my life.
      I came to terms with VSTS build steps and once back from holidays will be converting some of build steps into VSTS build steps. But some of steps will still be executed by Cake – like building LocalDB database for tests and packing nuget package. Not sure how much better this will be, but local build process is not the same as on VSTS build agent anyway.
      Don’t get me wrong, all my open-source projects on GitHub are built via Cake and I love it. But VSTS integration with Cake is a pain in the neck. Especially given that VSTS is moving so fast with new features.

      • SchmidtTroy

        So with the latest DotNet tasks being in 2.* (preview) they look like they are working better?

        One of the big reasons I am keeping Cake build going in VSTS is the ability to run OpenCover and ReportGenerator. Not to mention I can run the same build locally so I can review the HTML generated coverage faster. I am also looking to start using ReSharper Ultimate again so then I would be utilizing the code coverage within it using our xUnit tests.

        I’ll definitely keep posted on this blog.

        • Well, yes some VSTS tasks work great natively, some not so much.

          Ability to run the same build locally is indeed a great benefit, also having build script versioned the same way as the rest of your codebase is awesome – you can have different build for different branches. And over time your build script will evolve along with your code – and it’ll be versioned. Where as VSTS build will not be. Sometimes it is useful when you need to re-build an old version for some reason.

          As for running the same build locally – we realised that is almost never the case anymore. Amount of conditional steps that are executed on VSTS but never locally was staggering, so we stopped believing this.

          As for code coverage – we used to observe that religiously. Even had a build fail condition if coverage percentage drops a certain amount. But at some point coverage amount became a lot less relevant and actual test quality and relevance was a lot more important. So we stopped tracking this.

  • Michael

    Using my CI build on VSTS, I could not find the task type Nuget Command, so I took the regular Nuget task and selected the “custom” mode. Entering the command above gives me the following error :

    2017-11-16T18:54:02.0263030Z ##[error]Error: Unable to locate executable file: ‘mono’. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also check the file mode to verify the file is executable.

    What that means?

    • Sounds like you are running on Linux build agent. I’ve just tried the same stuff with the new NuGet step: https://i.imgur.com/z9f8oHD.png and did not get any errors

      • Michael

        I wrote the same command as you. However I forgot to mention that I’m using docker containers, so I may be forced to push the private source using compose config files.