您如何处理向后/向前的 .Net 框架兼容性（和软件分发）？答案

【问题标题】：How do you handle backwards/forwards .Net framework compatibility (and software distribution)?您如何处理向后/向前的 .Net 框架兼容性（和软件分发）？
【发布时间】：2015-11-25 21:19:41
【问题描述】：

假设我使用 .Net 4.5 创建了一个控制台应用程序（为简单起见，对 GUI 或 Web 框架的版本没有复杂的依赖关系）。明年，“.Net 5”发布，我想更新我的应用程序以使用花哨的新 API（以提高性能、源代码可读性等）。但是，我仍然希望为尚未升级其运行时的用户维护（关键错误修复等）应用程序的先前版本。

这种情况如何处理？我是否需要提供 2 个可执行文件并要求用户下载合适的那个，或者有没有办法分发一个可执行文件/安装程序来确定自动运行哪个版本？

或者，这甚至是一个有效的问题吗？如果我想继续支持“旧”.Net 4.5 上的用户，我是否有义务继续仅针对该框架进行构建？

【问题讨论】：

旁注：当您真正知道要使用哪些功能时，最好问这个问题...至少澄清您是否正在寻找 C# 语言功能，真正的代码 .Net 程序集更改或 NuGet 更新。
同意了，可能到时候再问。我现在这样问是因为我想要对整个问题有更多一般性的答案，而不仅仅是针对我手头的问题的具体解决方案。事实上，我是在问一个我还没有开始的项目的问题——我只是想从正确的角度开始。我真的不知道我将来要使用哪些功能（显然）。
如果您真的想摆脱这个麻烦，请使用 .NET Core 并在部署时将运行时与您的应用程序捆绑在一起。然后，您的最终用户甚至不必安装 .NET Framework 并担心兼容性问题。然而，负担变成了你的负担，你必须经常更新你的应用程序部署，因为 .NET Core 运行时升级经常带有安全修复程序。更多内容可向dot.net了解详情

标签： c# .net clr compatibility

【解决方案1】：

像Wix Toolset 这样的许多安装程序可能会提供implement custom actions 的方法，这样您就可以检测目标系统中安装的最新框架版本是什么，并决定在那里部署什么可执行文件。 Check this Wix Toolset article about .NET Framework version detection.

另一方面，如果您想使用以前框架版本中不可用的新功能并合并更改并使它们兼容，则需要为每个目标框架版本维护一个源代码分支。

如果您的代码使用的功能非常有限，you can still use preprocessor directives 像 #if NETFX_45 或任何您可以添加到项目中的编译符号，并根据预处理器条件编译为一个或其他框架版本。

无论如何，您的最终解决方案将是正确处理代码版本控制和创建自定义安装程序操作以检测用户目标系统的组合。

【讨论】：