.NET Standard 2.0 使用的兼容性垫片 [英] Compatibility shim used by .NET Standard 2.0
问题描述
.NET Standard 2.0 的概述(
这显示了该场景应该如何工作:当第 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 被阻塞.
Overviews (example) of .NET Standard 2.0 say that it now uses some kind of compatibility shim that fixes the third-party library compatibility issue. So you can use the third-party library with .NET Standard until it doesn't use any API which .NET Standard doesn’t have.
What is not clear is
- how does this shim work? any drawbacks?
and
- how to check that third-party library is supported? By directly adding it into the project and then trying to compile?
This works by creating all the necessary libraries that are referenced by classic .NET libraries.
E.g. in .NET Core the implementation of Object or Attribute is defined in System.Runtime. When you compile code, the generated code always references the assembly and the type => [System.Runtime]System.Object. Classic .NET projects however reference System.Object from mscorlib. When trying to use a classic .NET assembly on .NET Core 1.0/1.1, this usually leads to types not being found. In .NET Core 2.0, there will be "fake" types in a mscorlib that the runtime knows how to forward to where the implementation actually is.
You can read more about how this assembly unification works on the dotnet/standard GitHub repo but the most important scenario is this (image taken from this repository):
This shows how the scenario is supposed to work: When a 3rd party dll references [mscorlib]Microsoft.Win32.RegistryKey, there will be an mscorlib.dll that contains a type forward to [Microsoft.Win32.Registry] Microsoft.Win32.RegistryKey so it will work when a Microsoft.Win32.RegistryKey.dll is present.
This also shows the major downside: The registry is a windows-only concept and not available on Mac or Linux so this particular code may fail to run on non-windows platforms. But if you use only parts of the library that do not use this functionality, it may work for cross-platform scenarios.
Another problem is that even if API is "available" to compile against and reference, it still may throw a PlatformNotSupportedException.
For example, a library that implements a file format for serialisation / deserialisation might work without modification, even if it has been built for .NET Framework 3.5.
To find what API functions a particular library uses, the .NET Portability Analyzer can be used to scan a dll and show if the library is compatible and if not, which APIs are blocking.
这篇关于.NET Standard 2.0 使用的兼容性垫片的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
