.net core .NET标准2.0使用的兼容性垫片

.NET标准2.0的概述（）说，它现在使用某种兼容性垫片来修复第三方库的兼容性问题。因此，您可以将第三方库与.NET标准一起使用，直到它不使用任何.NET标准没有的API为止

不清楚的是

• 这个垫片是怎么工作的？有什么缺点吗

及

• 如何检查是否支持第三方库？直接将其添加到项目中，然后尝试编译

---

这通过创建经典.NET库引用的所有必要库来实现

例如，在.NET内核中，

对象

或

属性

的实现在

系统运行时

中定义。编译代码时，生成的代码始终引用程序集和类型=>

[System.Runtime]System.Object

。然而，经典的.NET项目引用了

mscorlib

中的

System.Object

。当尝试在.NET Core 1.0/1.1上使用经典的.NET程序集时，通常会导致找不到类型。在.NET Core 2.0中，运行时知道如何将

mscorlib

中的“假”类型转发到实现的实际位置

您可以阅读更多关于如何实现这一点的信息，但最重要的场景是（从该存储库拍摄的图像）：

这显示了该场景的工作方式：当第三方dll引用Microsoft.Win32.RegistryKey时，将有一个包含转发到

[Microsoft.Win32.Registry]的类型的
mscorlib.dll
Microsoft.Win32.RegistryKey

，因此当存在

Microsoft.Win32.RegistryKey.dll时，它将工作

这也显示了主要的缺点：注册表是一个仅适用于windows的概念，在Mac或Linux上不可用，因此此特定代码可能无法在非windows平台上运行。但是，如果只使用库中不使用此功能的部分，则它可能适用于跨平台场景

另一个问题是，即使API“可用”进行编译和引用，它仍然可能抛出
平台NotSupportedException

例如，实现用于序列化/反序列化的文件格式的库可能不需要修改就可以工作，即使它是为.NET Framework 3.5构建的

要查找特定库使用的API函数，可以使用扫描dll并显示库是否兼容，如果不兼容，哪些API被阻止。
我如何注意引用的.NET Framework库是否与.NET标准兼容？这是编译时错误还是运行时错误？@leppie注释不适用于答案：）