概述(example).NET Standard 2.0 表示它现在使用某种兼容性填充程序来修复第三方库兼容性问题。因此,您可以将第三方库与 .NET Standard 一起使用,直到它不使用 .NET Standard 没有的任何 API。
不清楚的是
and
- 如何检查是否支持第三方库?直接添加到项目中然后尝试编译?
这是通过创建经典 .NET 库引用的所有必要库来实现的。
例如。在.NET Core中的实现Object
or Attribute
定义于System.Runtime
。编译代码时,生成的代码始终引用程序集和类型 =>[System.Runtime]System.Object
。然而经典的 .NET 项目参考System.Object
from mscorlib
。当尝试在 .NET Core 1.0/1.1 上使用经典 .NET 程序集时,这通常会导致找不到类型。在 .NET Core 2.0 中,a 中将会存在“假”类型mscorlib
运行时知道如何转发到实际实现的位置。
您可以阅读更多关于如何做到这一点的信息程序集统一适用于 dotnet/standard GitHub 存储库但最重要的场景是这样的(图片取自此存储库):
这显示了该场景应该如何工作:当第 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 可移植性分析器可用于扫描 dll 并显示该库是否兼容,如果不兼容,则显示哪些 API 被阻止。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)