.NET Standard 2.0使用的兼容性垫片

Question

.NET标准2.0的概述(示例)表示它现在使用某种兼容性填充程序来修复第三方库兼容性问题.因此,您可以将第三方库与.NET Standard一起使用,直到它不使用.NET Standard没有的任何API.

目前尚不清楚的是

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

和

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

Answer 1

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

例如,在.NET Core中实现Object或Attribute定义System.Runtime.编译代码时,生成的代码始终引用程序集和type => [System.Runtime]System.Object.然而经典.NET项目中引用System.Object的mscorlib.尝试在.NET Core 1.0/1.1上使用经典.NET程序集时,通常会导致找不到类型.在.NET Core 2.0中,将存在"假"类型,mscorlib运行时知道如何转发到实现的实际位置.

您可以在dotnet /标准GitHub存储库中阅读有关此程序集统一的工作原理的更多信息,但最重要的情况是此(从此存储库获取的图像):

这显示了场景应该如何工作:当第三方dll引用时[mscorlib]Microsoft.Win32.RegistryKey,将会有一个mscorlib.dll包含转发类型的内容,[Microsoft.Win32.Registry] Microsoft.Win32.RegistryKey因此当a Microsoft.Win32.RegistryKey.dll存在时它将起作用.

这也显示了主要的缺点:注册表是一个仅限Windows的概念,在Mac或Linux上不可用,因此这个特定的代码可能无法在非Windows平台上运行.但是,如果您仅使用不使用此功能的库的某些部分,则它可能适用于跨平台方案.

另一个问题是,即使API"可用"来编译和引用,它仍然可能会抛出一个PlatformNotSupportedException.

例如,实现序列化/反序列化的文件格式的库可能无需修改即可工作,即使它是为.NET Framework 3.5构建的.

要查找特定库使用的API函数,可以使用.NET可移植性分析器扫描dll并显示库是否兼容,如果不兼容,哪些API是阻塞的.