CODEWITHSUNDEEP
.netmsbuilddependency-management.net-standard
Mason Wheeler
Mason Wheeler

Reputation: 84650

What's needed to have a .NET Framework project reference a .NET Standard assembly?

I have a project that's built against .NET Framework 4.6.2. One of its dependencies is an assembly built against .NET Standard 2.0.

It was building just fine before, on my old computer, but now I have a new dev system I'm setting up, and when I try to run the build, with the same version of the same tools, I get a few dozen errors about the Netstandard DLL referencing a bunch of the little single-namespace assemblies that are popular in .NET Core. For example:

The primary reference "Foo" could not be resolved because it has an indirect dependency on the framework assembly "netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51" which could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.6.2". To resolve this problem, either remove the reference "Foo" or retarget your application to a framework version which contains "netstandard, Version=2.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51". (MSB3268)

If I explicitly add a project reference to Netstandard 2.0 from the GAC, the error becomes:

The primary reference "netstandard", which is a framework assembly, could not be resolved in the currently targeted framework. ".NETFramework,Version=v4.6.2". To resolve this problem, either remove the reference "netstandard" or retarget your application to a framework version which contains "netstandard". (MSB3267)

Again, this built (and still does build) without errors on the old system, and I'm trying to build the project without any changes on the exact same IDE and compiler. So I can only assume that I'm missing something that needs to be installed on my dev system, but I'm not quite sure what it is.

Has anyone run into this before? I found a few other questions on here about trying to reference a Netstandard assembly from a C# .NET Framework project, and apparently it's tricky because of some Roslyn-related details, but I'm actually using the Boo language in my NET Framework project, so none of those questions are particularly relevant, plus it did work just fine before.

This feels like it should have a really simple answer if I just knew what detail I was overlooking...

Upvotes: 4

Views: 1654

Answers (1)

jnm2
jnm2

Reputation: 8364

The .NET team has been strongly suggesting moving to net472 due to a plethora of issues with the toolchain trying to retrofit .NET Standard 2.0 support onto net461–net471. If upgrading is an option for you, it will save a lot of time. .NET Framework 4.7.2 also has the side benefit of not requiring dozens of shim DLLs to be present in your bin output, and of course there are the minor enhancements that come with any .NET Framework upgrade. (Release notes: net47, net471, net472.)

https://twitter.com/terrajobst/status/1031999730320986112:

Sorry but we messed up. We tried to make .NET Framework 4.6.1 retroactively implement .NET Standard 2.0. This was a mistake as we don't have a time machine and there is a tail of bugs. If you want to consume .NET Standard 1.5+ from .NET Framework, I recommend to be on 4.7.2.

Note that that this has nothing to do with missing APIs (although .NET Framework 4.6.1 misses about 100 APIs). It's all about binding policy, assembly identities, and treatment of framework assemblies in tooling (MSBuild, ClickOnce, test runners etc).

The lesson learned here is simple: once shipped, a given version of a .NET implementation must not change the support level of .NET Standard. IOW, the supported .NET Standard number is an immutable property. Supporting a higher version requires shipping a new version.

Upvotes: 7

Related Questions