.Net Standard is specification.

  1. There are two popular implementation of the .net standard specification. ie .Net Core & .Net Framework
  2. When I create .Net Standard library, I am allowed to refer this in .Net core project as well as .Net Framework project. This makes absolute sense to me.
  3. I am allowed to reference a .Net Framework library in a .Net Standard library. When I do this I am no more able to refer the .Net Standard library in any .Net Core applications. Why are we permitted to reference a .Net framework library in .Net standard?

This is defeating the purpose on .Net standard in my understanding. Or am I getting it wrong?

  • In short the main reason behind this is that .NET Framework can be used only on Windows machines, whereas .NET Core on Linux and macOs as well. Let's suppose you include a library which relies on a Windows API call, then do you guarantee that it will run on Linux or macOs machiens? Commented Sep 9, 2020 at 8:31
  • I understand why it further blocks the reference of such .net standard library in .net core app. And here its a run time exception not a issue at compile time. The reason for my question: In my org we created a .net standard library hoping it to be consumable from .net core and .net framework apps. But a developer made this .net standard library refer a .net framework library and tested it with .net framework client. Now others who are trying by build a .net core apps out of this is facing a problem. The intention of creating a .net standard library is lost for us now Commented Sep 9, 2020 at 9:00
  • 1
    A way to ensure that this doesn't happen again in future could be to include automated tests for the library in both .NET Framework and .NET Core to catch any portability issues early on. Commented Sep 9, 2020 at 9:53

3 Answers 3


I read your question as "what is a real-world use case for referencing a .Net framework library from a .Net standard library", since it defeats the purpose of .Net standard to be compatible with .Net Core.

The main use case I can think of where this szenario makes sense is "easier porting" / "porting in parallel". Let us say one wants to develop a .Net standard library S which needs another library F which is currently only available as a .Net framework implementation. F is planned be ported to .Net standard within the next 3 months. So S can be developed and tested now, using the current version of F, whilst F is ported to .Net standard in parallel. When F will be available then as a .Net standard version, the only thing which ideally remains is to change the reference from S to the new version of F, which makes S compatible with .Net core.

  • 1
    Yeah.. this makes sense... Shouldn't there be a way to tell that "S is not fully a .Net Standard library and it has dependency on .Net framework"? Commented Sep 9, 2020 at 9:30
  • 2
    @NachiappanKumarappan: maybe there is one? I don't know, but I guess that could be a good question for Stack Overflow
    – Doc Brown
    Commented Sep 9, 2020 at 10:50
  • I'm working on an addon framework for FiveM. THe server code supports netstandar2.0 but the client end is sandboxed with mono to Framework 4. The client is so locked down that even though MS list it as supported my 4.7.1 client code can't load netstandard 2.0 dlls. These are shared with server, but the only way I could go is to make my core framework dlls 4.7.1 which puts me in the scenario of netstandard back referencing 4.7.1. My data access is using EF Core so I don't want to make my server code 4.7.1. Stuck in the middle. Commented Feb 12, 2022 at 12:33

The other way to look at it is that .NET standard, being a specification, is like an interface. Whenever you add a reference to a .NET standard library, as long as the reference meets the specification definition, then the library doesn't care what type it is. Implementation is separate from specification.

As you said, if you add a .NET framework library to a .NET standard library, then you can no longer run it on .NET Core, but this is a runtime issue rather than an edit time or compile time issue.


This works due to the .NET Framework compatibility mode: https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0#net-framework-compatibility-mode

TLDR; it might work, but things could blow up at runtime if code is executed that is not .NET Standard 2.0 compatible

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.