问题
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?
回答1:
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.
回答2:
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.
回答3:
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
来源：https://stackoverflow.com/questions/53148385/if-net-core-can-run-on-windows-why-cant-you-reference-a-net-core-dll-in-net