.NET Standard 2.0 的概述 (example) 说它现在使用某种兼容性填充程序来修复第三方库的兼容性问题。因此，您可以将第三方库与 .NET Standard 一起使用，直到它不使用 .NET Standard 所没有的任何 API。
不清楚的是
和
【问题讨论】：
这是通过创建经典 .NET 库引用的所有必要库来实现的。
例如在 .NET Core 中，Object 或 Attribute 的实现在 System.Runtime 中定义。编译代码时，生成的代码始终引用程序集和类型 => [System.Runtime]System.Object。然而，经典 .NET 项目从 mscorlib 引用 System.Object。当尝试在 .NET Core 1.0/1.1 上使用经典的 .NET 程序集时，这通常会导致找不到类型。在 .NET Core 2.0 中，mscorlib 中会有“假”类型，运行时知道如何转发到实际的实现位置。
您可以阅读更多关于assembly unification works on the dotnet/standard GitHub repo 的信息，但最重要的场景是这样的（图片取自此存储库）：
这显示了场景应该如何工作：当第 3 方 dll 引用 [mscorlib]Microsoft.Win32.RegistryKey 时，将有一个 mscorlib.dll 包含一个转发到 [Microsoft.Win32.Registry] Microsoft.Win32.RegistryKey 的类型，因此当存在 Microsoft.Win32.RegistryKey.dll 时它会工作.
这也显示了主要的缺点：注册表是一个仅限 Windows 的概念，在 Mac 或 Linux 上不可用，因此此特定代码可能无法在非 Windows 平台上运行。但如果您只使用库中不使用此功能的部分，它可能适用于跨平台场景。
另一个问题是，即使 API 是“可用于”编译和引用的，它仍然可能抛出 PlatformNotSupportedException。
例如，实现序列化/反序列化文件格式的库无需修改即可工作，即使它是为 .NET Framework 3.5 构建的。
要查找特定库使用的 API 函数，.NET Portability Analyzer 可用于扫描 dll 并显示该库是否兼容，如果不兼容，哪些 API 被阻塞。
【讨论】：