0

I get why .Net Framework could cause issues in .Net Core, IE because an API specific to the Windows platform doesn't exist. But why wouldn't you be able to directly reference .Net Core as a library in .Net Framework? If .Net Core runs on windows, what is preventing a .Net Framework app from using .Net Core as if it were a library?

I'm aware that you can port the .Net Core library to a .Net Standard Library, but my question is why .Net Framework can't just reference anything written in .Net Core, since it is cross platform anyway?

FakeSaint
  • 492
  • 5
  • 8
  • .Net Framework build on .Net Framework 4.7 or below but .NetCore is higher of them. How can it run? – Md. Abdul Alim Nov 05 '18 at 05:15
  • @FakeSaint: What you should do is to create a *.NET Standard* project. You will be able to reference this one from applications running on the .NET Framework and .NET Core. These are two separate runtimes. – mm8 Nov 05 '18 at 08:57
  • Yea thanks, I know about .Net Standard. My confusion is why you couldn't just include the .net core class library as a dependency in a .net framework project – FakeSaint Nov 05 '18 at 20:22

3 Answers3

5

Currently, there are not only APIs in .NET Framework that is not available in .NET Core (e.g. Remoting, WCF hosting, additional App Domains), but there are now also APIs in .NET Core that aren't available on .NET Framework - this includes useful additions to the base class library and a lot of Span<T> based APIs that have been added to base .NET types in .NET Core 2.1.

In order to create libraries that can be used on both frameworks, use .NET Standard.

Technically, the biggest difference between .NET Framework and .NET Core is where (.dll files) the frameworks actually carry their implementations and type definitions.

While .NET Framework has a lot of base types in mscorlib.dll, .NET Core may carry them inside System.Runtime.dll or System.Private.CoreLib.dll.

A type reference always includes the name of the assembly and the namespace+type name. If the framework you run on has System.Object defined in mscorlib but an application references [System.Runtime]System.Object, it may fail to load.

.NET Core 2.0 has invested effort to at least provide type forwarders so that references are redirected to the correct assemblies. So the .NET Framework compatibility may redirect [mscorlib]System.Object to [System.Runtime]System.Object when loading .NET Framework assemblies. (see Compatibility shim used by .NET Standard 2.0)

The same may not work the other way around. While newer versions of .NET Framework provide a lot of the same assemblies (implemented via type forwarding) that .NET Core uses, it only guarantees .NET Standard compatibility. If you target older versions of .NET Framework, additional type forwarding DLLs will be added to the build output to provide this compatilbity (see Why does my .NET Standard NuGet package trigger so many dependencies?).

This may enable loading some .NET Core dll files on .NET Framework to some degree, but there is no guarantee that it may work. It will fail if the dll uses APIs unavailable on .NET Framework but may also fail when it references a type with an assembly name that is not available.

Note that this only applies to loading dll files. Project-to-Project references will fail since the tooling should forbid referencing .NET Core projects from .NET Framework projects.

Martin Ullrich
  • 94,744
  • 25
  • 252
  • 217
  • Thanks I appreciate it! But why would type forwarding be necessary at all if you are referencing a .net Core Library in .Net Framework? What is preventing you from including the entire .net Core runtime assemblies, like System.Runtime as a dependency in .Net Framework? – FakeSaint Nov 05 '18 at 20:45
  • If the types cannot be unified (say, two competing definitions of `System.Object`), no type exchanges would be possible. Even assembly unification is complicated, and many types in .NET Core rely on native assets or runtime (CoreCLR) features that wouldn't work on the .NET Framework CLR. But I guess that's now really out of scope, may answer is probably way too detailed already.. – Martin Ullrich Nov 05 '18 at 21:08
  • Thank you so much for such a thorough answer! Given me lots to think about – FakeSaint Nov 05 '18 at 21:36
3

Being cross-platform has nothing to do with it. .NET Core and .NET Framework are entirely distinct and separate frameworks. .NET Standard is essentially an interface that exposes common APIs. .NET Core 2.0+ implements .NET Standard 2.0, plus its own unique APIs. .NET Framework 4.6.1+ implements .NET Standard 2.0, as well, plus its own unique APIs. Technically, for either, you can only reference a library that targets .NET Standard or that targets the same framework (.NET Core to .NET Core and .NET Framework to .NET Framework).

However, because there's so many .NET Framework libraries out there, many of which are perfectly compatible with .NET Standard, but have not been updated to specifically target .NET Standard, Microsoft essentially made an exception in the compiler to specifically allow you to reference .NET Framework libraries in things compatible with .NET Standard 2.0 like .NET Core 2.0. However, when you do so, you get a warning that the library may not actually be compatible. For example, if it uses any of the APIs unique to .NET Framework, then your app will blow up, when targeting .NET Core. It's on you as the developer to test and ensure that the library is compatible.

Long and short, the fact that you can reference .NET Framework libraries in .NET Core projects is deceptive. It's basically treating the .NET Framework library as if it's a .NET Standard library, which in most cases works fine. However, no special dispensation is made for the other way around.

Chris Pratt
  • 232,153
  • 36
  • 385
  • 444
  • Thanks! My specific confusion though is why you can't just include the .Net core framework as a reference from within a .Net Framework app. That way any API specific to .net Core would just use the referenced .net core assemblies. – FakeSaint Nov 05 '18 at 20:54
  • Because the framework doesn't come with the package. If you're targeting .NET Framework, then it has to be able to build with just .NET Framework, which is not possible for a .NET Core library. – Chris Pratt Nov 05 '18 at 21:59
  • 1
    You *could* multi-target, but I'm not sure if that would actually work. At the very least you'd probably have to employ compile-time directives, which is a pain, and not a very good practice. – Chris Pratt Nov 05 '18 at 22:01
  • Thanks for your help! – FakeSaint Nov 05 '18 at 22:29
0

Compatibility: .NET Core does not support all the features and functionalities provided by the latest version of .NET Framework. But it can be used as a subset of the .NET Framework. Also, .NET Core is still compatible with .NET Framework through the .NET Standard Library. Hence, the developers can still run the applications developed with .NET Framework after upgrading to .NET Core.

Please go through this before merging these two frameworks:
What's the difference between .NET Core, .NET Framework, and Xamarin?
.NET Core, .NET Framework, Xamarin – The “WHAT and WHEN to use it”
Difference between .Net Core and .Net Framework
.NET Core vs .NET Framework: How to Pick a .NET Runtime for an Application

Niranjan Singh
  • 18,017
  • 2
  • 42
  • 75