如果.Net Core可以在Windows上运行，为什么不能在.Net Framework中引用.Net Core DLL？

我明白为什么 .Net Framework 可能会在 .Net Core、IE 中导致问题，因为不存在特定于 Windows 平台的 API。但是为什么不能直接引用 .Net Core 作为 .Net Framework 中的库呢？如果 .Net Core 在 Windows 上运行，是什么阻止 .Net Framework 应用程序像使用库一样使用 .Net Core？

我知道您可以将 .Net Core 库移植到 .Net 标准库，但我的问题是为什么 .Net Framework 不能引用用 .Net Core 编写的任何内容，因为它无论如何都是跨平台的？

目前，.NET Framework 中不仅有 .NET Core 中不可用的 API（例如远程处理、WCF 托管、其他应用程序域），而且 .NET Core 中也有 .NET Framework 中不可用的 API - 这包括对基类库的有用补充和许多Span<T>已添加到 .NET Core 2.1 中基本 .NET 类型的 API。

为了创建可在这两个框架上使用的库，请使用 .NET Standard。

从技术上讲，.NET Framework 和 .NET Core 之间的最大区别在于框架实际携带其实现和类型定义的位置（.dll 文件）。

虽然 .NET Framework 有很多基本类型mscorlib.dll，.NET Core 可能会将它们带入内部System.Runtime.dll or System.Private.CoreLib.dll.

类型引用始终包含程序集的名称和命名空间+类型名称。如果您运行的框架有System.Object定义于mscorlib但有一个应用程序参考[System.Runtime]System.Object，可能会加载失败。

.NET Core 2.0 投入了精力，至少提供类型转发器，以便将引用重定向到正确的程序集。因此 .NET Framework 兼容性可能会重定向[mscorlib]System.Object to [System.Runtime]System.Object加载 .NET Framework 程序集时。 （看.NET Standard 2.0 使用的兼容性填充程序 https://stackoverflow.com/questions/44464937/compatibility-shim-used-by-net-standard-2-0/44492663#44492663)

反之亦然。虽然较新版本的 .NET Framework 提供了许多与 .NET Core 使用的相同的程序集（通过类型转发实现），但它仅保证 .NET Standard 兼容性。如果您以旧版本的 .NET Framework 为目标，则会将其他类型转发 DLL 添加到生成输出中以提供此兼容性（请参阅为什么我的 .NET Standard NuGet 包会触发如此多的依赖项？ https://stackoverflow.com/questions/47365136/why-does-my-net-standard-nuget-package-trigger-so-many-dependencies).

这可能会在某种程度上允许在 .NET Framework 上加载某些 .NET Core dll 文件，但不能保证它可以工作。如果 dll 使用 .NET Framework 上不可用的 API，它将失败，但当它引用具有不可用的程序集名称的类型时，也可能会失败。

请注意，这仅适用于加载 dll 文件。项目到项目的引用将会失败，因为工具应禁止从 .NET Framework 项目引用 .NET Core 项目。