Presently sponsored by: ScriptRunner - Get your free PowerShell Cheat Sheet!

I recently upgraded some projects to .NET 5 from the previous .NET Core 3.x versions I had running. My projects utilize xUnit, and I run them from Azure DevOps.

However, when I upgraded my projects, and modified the build definition accordingly with the latest NuGet installer, and the latest .NET 5 SDK, I got a new exception:

##[error]Unable to find D:\a\1\s\src\projectname\bin\Debug\net5.0\ref\projectname.deps.json. Make sure test project has a nuget reference of package "Microsoft.NET.Test.Sdk".

Looking closely on the path, it mentions a path I wasn't expecting:/ref/. With this path, I didn't have the deps.json file.

Here's some additional info about the reference assemblies.

Multiple identical files were discovered, and the wrong one was picked

The tests now discovered two files with identical names, one where the deps.json file exists, and one where it doesn't. When understanding that, the solutions are easier to craft.

Solution 1. Set ProduceReferenceAssembly to false

In your .csproj file,  you can find configure the reference assemblies to be disabled. Since I don't need them for my xUnit test project right now, I can easily do that.

Listed in the common properties and parameters on Microsoft Docs:


A boolean value that when set to true enables production of reference assemblies for the current assembly. Deterministic should be true when using this feature. This property corresponds to the /refout switch of the vbc.exe and csc.exe compilers.

Here's the modification you should drop into your .csproj file.


That's one way to do it.

Solution 2. Ignore the /ref/ folder in your test tasks in Azure DevOps

You can also opt to fix it on the test-run side. In my case, I'm using Azure DevOps.

If you're using the visual editor, this is how you can add the exclusion of the ref folder:

Ignore the /ref/ path in Azure DevOps, to allow .NET 5 xunit tests to run again.

If you're using YAML, here's an example of how can do it:

- task: VSTest@2
  displayName: 'Run Tests'
    testAssemblyVer2: |
    diagnosticsEnabled: True

There we have it. Something that bothered me for a few moments until I could spot the /ref/ in the path - I hope it can help someone else save time.