Following my previous post, I’m building Asp.Net Core web application and I’m running my tests in XUnit. Default VSTS template for Asp.Net Core application runs the tests but it does not publish any results of test execution, so going into Tests results panel can be sad:

And even if you have a task that publishes test results after dotnet test, you will not get far.

As it turns out command dotnet test does not publish any xml files with tests execution results. That was a puzzle for me.

Luckily there were good instructions on XUnit page that explained how to do XUnit with Dotnet Core properly. In *test.csproj file you need to add basically the following stuff:

<Project Sdk="Microsoft.NET.Sdk">


    <PackageReference Include="xunit" Version="2.3.0-beta2-build3683" />
    <DotNetCliToolReference Include="dotnet-xunit" Version="2.3.0-beta2-build3683" />


Make sure you don’t miss the DotNetCliToolReference line – this is the key here.

Run dotnet restore and dotnet xunit inside the folder with this project. If you try to run this command outside of this folder you’ll get an error.

Command dotnet xunit has an option to output test results as XML file: dotnet xunit -xml .\test-results.xml.

Because this needs to be executed inside of the tests folder we can’t use “.Net Core” build task from VSTS – there is no option to configure what is the base execution folder. Instead you can just add “Command Line” task to execute what we need and from the correct folder:

Add “Command Line” task. As Tool option give it dotnet, for arguments say xunit -xml ./test-results.xml and make sure you specify the working folder – for my case that was src/Tests.

After that add “Publish Test Results”, tell it to use XUnit format, the rest of the default parameters worked for me.

And BOOM! We have tests results published at the end of the build:

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 -username -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.