使用 .NET 5.0 中的类型，同时保持与早期 .NET 版本（如 .NET Core 3.1）的兼容性答案

【问题标题】：Use types from .NET 5.0 while remaining compatible with earlier .NET versions like .NET Core 3.1使用 .NET 5.0 中的类型，同时保持与早期 .NET 版本（如 .NET Core 3.1）的兼容性
【发布时间】：2020-09-07 16:16:23
【问题描述】：

假设您希望使用 the new System.Half，但您还希望您的库可供 .NET Core 3.1 应用程序（或更早版本）使用。我可以简单地复制 System.Half 实现并失去旧 .NET 版本的内在优化行为，但我可以在单个程序集中这样做吗？

据我所知，这是不可能的（除非采用反射式方法，或者在首次使用时发出 IL 的疯狂行为）：上述场景需要使用内置的 .NET 5.0 单独构建System.Half) 和较早的 .NET 版本（使用我们内部的 System.Half）。

但我希望是否有某种方法可以编译/配置带有一些创造性类型转发的单个程序集，以便在可用时利用给定类型的 .NET 5.0 版本，否则使用 shim。

（这个问题与语言无关，不仅仅针对System.Half）

【问题讨论】：

标签： c# .net-core clr coreclr .net-5

【解决方案1】：

简而言之：不，在单个程序集中是不可能的 - 这需要通过多目标库 5.0+ 和您想要的 .NET CCore 的最低版本来完成支持并创建此库的 NuGet 包。

然后使用该库的应用程序将选择最匹配的程序集，因此 .NET 5/6/+ 应用程序将使用运行时的 System.Half 实现获得您的 .NET 5.0 切片，而 .NET Core 3.1 应用程序将获得另一个包含您在 #if 后面的 System.Half 实现。

即使您不想多目标库，也需要一个不同的 NuGet 包，为 .NET (Core)

【讨论】：

谢谢，这涵盖了我对当前可能性的理解。很不幸。我可以想象编写一个类型的公共版本，它只是在调用时抛出NotImplementedException，并且以某种方式标记有TypeDelayImplemented 属性，表明如果加载路径包含该类型的匹配版本，则使用它。虽然那条路上会有很多荆棘。

【解决方案2】：

通常，它归结为：是否有可用的 nuget 包提供 API 的某些部分？请注意，对于像Half 这样的原语，即使有一个 nuget 包，它也可能以不同的方式实现 - 即没有内置的 JIT/内在支持 - 但它可能仍然有效。例如，考虑Span<T>，它在下层框架中工作（通过 nuget），但在 .NET Core 3.1 或更高版本中最佳。再举一个例子，考虑IAsyncDisposable/IAsyncEnumerable<T>，可以通过 nuget 包获得。

【讨论】：

是的，但这里的主要问题是：我能否配置一个单个程序集/dll，使其在引用时毫不费力地选择一个？特别是，我根据implementing support for System.Half into FSharp.Core.dll 询问，它应该仍然是一个保持向后兼容的单一程序集。
@Abel 这就是包解析的“诱饵和切换”方面在多目标依赖关系的上下文中工作的意思 - 意思是：你不应该做任何事情，如果它已经使正确在 nuget 包中可用
我的意思是，我可以做一些类似#if NET50 的事情，但是在 JIT 链接时间，比如TypeForwardedTo，但在这种情况下正好相反，PleaseUseSystemTypeIfAvailableOtherwiseThisOne。这与FSharp.Core 在内部还不能使用Span 的原因相同：它不能依赖NetStandard 之外的其他程序集。
@Abel 的类型必须是可识别为相同的运行时;这意味着如果它被打包在不同的库中，那个库会用类型转发信息声明它；但是，作为消费者：您不必做任何事情。这就是您使用的大多数类型已经发生的情况。
我想我们在这里谈论的是不同的事情。如果 Lib X 只能依赖于 NetStandard，我如何构建 X.dll 以便它使用来自 System.Runtime 的 Span（或 System.Half），如果它不可用，还有其他东西？运行时要么总是选择我自己开发的Span，要么总是使用系统Span，但后者不向后兼容，我无法混合和匹配（或者我错过了一些东西）。