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

Question

我明白为什么 .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 编写的任何内容，因为它无论如何都是跨平台的？

Answer 1

目前，不仅 .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框架有很多基本类型中mscorlib.dll，.NET Core可能进行内部他们System.Runtime.dll或System.Private.CoreLib.dll。

类型引用始终包括程序集名称和命名空间+类型名称。如果您运行的框架已在 中System.Object定义mscorlib但应用程序引用了[System.Runtime]System.Object，则它可能无法加载。

.NET Core 2.0 已投入精力至少提供类型转发器，以便将引用重定向到正确的程序集。因此 .NET Framework 兼容性可能会在加载 .NET Framework 程序集时重定向[mscorlib]System.Object到[System.Runtime]System.Object。（请参阅.NET Standard 2.0 使用的兼容性垫片）

反过来也一样。虽然较新版本的 .NET Framework 提供了许多与 .NET Core 使用的相同的程序集（通过类型转发实现），但它仅保证 .NET Standard 兼容性。如果您的目标是旧版本的 .NET Framework，额外的类型转发 DLL 将被添加到构建输出中以提供这种兼容性（请参阅为什么我的 .NET Standard NuGet 包会触发这么多依赖项？）。

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

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