Nix + DotNet / Mono; overcoming "You must add a reference to assembly 'netstandard'"

Using the shell.nix below, I’m struggling to get a .Net project to dotnet build without hitting errors like:

[CS0012] The type 'Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'.

The .Net project builds fine on Ubuntu, Windows and MacOS, requiring Mono and dotnet core to be installed beforehand. So, I’m confident it’s not a config problem within the project.

Here’s the shell.nix I’m experimenting with:

  pkgs = import <nixpkgs> { };
  dotnetCombined = with pkgs.dotnetCorePackages;
    combinePackages [


in pkgs.mkShell rec {
  name = "webdev";

  buildInputs = with pkgs; [
    #    dotnet-sdk_2
    #    dotnet-sdk_3
    #    dotnetCorePackages.netcore_3_1
    #    dotnetCorePackages.sdk_3_1
    #    dotnetPackages.Nuget


  # Fixes "The reference assemblies for .NETFramework,Version=v4.7.2 were not found"
  shellHook = ''
    export FrameworkPathOverride=${pkgs.mono}/lib/mono/4.7.2-api

The download page for mono on Ubuntu suggests using the mono-complete package will resolve most “assembly not found” errors; is that not already part of the mono derivation on nixpkgs?

I’ve added other notes on this problem to this gist.

do you mind posting a link to the code base?

I’m not entirely sure why dotnet restore wouldn’t fix this.

Sadly it’s a large proprietary codebase, and my attempts at shrinking it down to something shareable aren’t going well. Are there any tips or tricks to that, that I should know?

dotnet restore doesn’t seem to affect the problem.

the dotnet-sdk_2 and dotnet-sdk_3 both should be able to build .netframework==2.0 projects according to .NET Standard | Microsoft Docs

Most likely your mono usage is preventing this as you need mono>=5.4 to build .netstandard==2.0

earlier I thought it was something to do with Mono, as the 6.x version in nixpkgs was still at 6.0.
But, after trying 6.10 via this helpful PR and trying 5.20 direct from nixpkgs, they both get the same You must add a reference to assembly 'netstandard' error.

Removing mono doesn’t seem to be an option; isn’t it required if the project targets .NET Framework?

most likely, netcore wont support .netframework until the release of .NET 5 , in which it will be the only actively maintained framework moving forward Introducing .NET 5 - .NET Blog

I’m confused ― if netcore doesn’t support .netframework, how is this .netframework project being developed on Linux / MacOS?

Just like the fix below for the “reference assemblies for .NETFramework,Version=v4.7.2 were not found” error¹, I feel like there must be something different in how Nix is preparing the environment, compared to FHS distros like Ubuntu…

¹ Without this in the shell.nix, builds will fail:

shellHook = ''
  export FrameworkPathOverride=${pkgs.mono}/lib/mono/4.7.2-api

I believe Mono implements parts of .netframework, but netcore is separate. Unfortunately I don’t have a good way to reproduce your results :frowning:

thanks jon! that last reply spurred me to somehow find this article, which points at some official documentation:

So I removed Mono and the export FrameworkPathOverride=... line from the shell.nix, then added Microsoft.NETFramework.ReferenceAssemblies 1.0.0 to the projects that were triggering the errors; now running dotnet build succeeds! :partying_face:

I still have no idea why the solution worked without that package on other Linux machines, but not on NixOS… Was I not setting mono up correctly? :man_shrugging:

I would’ve liked to know why mono wasn’t working, but trying to shrink the project down to an SSCCE was such a time sink, so many moving parts. Hopefully this helps the next person though!

IIRC, previous versions of dotnet would restore packages relative to the executable. On NixOS, this means it would try to place items into the nix-store.

My assumption would be that the packages were being downloaded, but the frameworkpathoverride was preventing dotnet from inspecting the new packages. But i would have to reproduce the error to confirm.

1 Like