在旧框架版本中使用的库中支持更新的 .NET 框架功能答案

【问题标题】：Support newer .NET framework features in library used in older framework version在旧框架版本中使用的库中支持更新的 .NET 框架功能
【发布时间】：2012-01-10 21:34:57
【问题描述】：

我有一个在 .NET 3.5 下编译的异步库，因为它被 .NET 3.5 应用程序使用，但如果有人想传入一个，我希望能够处理 .NET 4.0 CancellationTokens。为了包括.NET 4.0 的东西，我必须打破与 .NET 3.5 的兼容性。到目前为止我提出的唯一选择是只允许传入“对象”然后使用反射，但这会导致丑陋的公共接口......我想确保客户端代码传入正确编译时的对象类型，而不是运行时。

有没有什么方法可以在编译时绑定 .NET 4.0 对象，而不会对消费者应用程序引入不必要的依赖？要说“如果有就使用这个功能，如果没有就跳过它”？

【问题讨论】：

没有。由于您希望这些类型成为公共接口的一部分，因此您必须编译两个不同的版本。
我可以建议您的库的 4.0 版本和 3.5 版本可能更实用。
您可以使用类似 #if !NET_3_5 的指令，使用语句 #endif 来帮助减少代码量。不确定这是否是一个好习惯。

标签： .net types .net-3.5 cancellation

【解决方案1】：

您可以在单独的程序集中拥有需要 .NET 4.0 类型的公共接口，可能作为扩展方法 - 如果需要（例如，在 .NET 4 类型和主程序集中的类型内部进行交互）您可以在主 (.NET 3.5) 程序集中定义一个接口，并在 .NET 4 程序集中使用 .NET 4 类型的包装器来实现它，以完全避免反射。

【讨论】：

我喜欢这个，因为它处理传递问题：如果程序集 X 需要程序集 Y 需要程序集 Z，而 Z 需要 4.0，那么这意味着 X 和 Y 需要 4.0。但是通过扩展方法，Z' 可以包含 4.0 的东西，Y 可以保持 3.5，X 仍然可以通过包含 Z' 来使用 4.0 的东西。主要缺点是您仅限于可以使用扩展方法实现的功能。这会使 CancellationTokenRegistration 的处理更加混乱，但并非不可能。
因此您将 CancellationTokenRegistration 包装在一个实现接口（在 Y 中定义）的类中（在 Z 中）。