.NET Standard 2.0使用的兼容性填充程序 [英] Compatibility shim used by .NET Standard 2.0

问题描述

.p Standard 2.0的

概述（

这显示了方案的工作原理：当第三方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函数，<一个href = https://github.com/Microsoft/dotnet-apiport rel = nofollow noreferrer>。NET可移植性分析器可用于扫描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屋！