.net - 针对多个 .NET 版本构建系统

Question

设计允许针对具有不同功能集的多个 .NET 版本的构建系统/项目结构的常见做法是什么？

具体来说:

• 您应该在源代码管理中分支吗？
• 你应该使用条件编译吗？
• 您是否应该派生接口(interface)，从而对它们进行版本控制？
• 您应该创建单独的“versionX”项目并链接公共(public)项目文件吗？

Answer 1

我已经尝试了几种不同的方法来做到这一点。

我排除了分支，因为使用 SVN/TFS 使所有分支保持同步有点困难。分布式 SCC 确实对分支/合并有更高级的支持，所以如果我转换的话，我打算重新考虑这种方法。

我将条件编译与使用链接源文件的特定版本项目一起使用。我按照这些思路完成的最激进的库是 Nito.Linq ，尚未发布。不过，您可以查看源代码，了解我是如何设置项目的。它currently targets 3.5、4.0、SL3 和 SL4，并且每个都有“有 Rx”和“没有 Rx”的变体。我也有 CF 3.5，但 VS2010 不支持它。

这种方法有一些缺点:

• 在我的解决方案中，我定义了一个“Sources”项目作为文件的容器。不幸的是，它是在加载时构建的，我无法在卸载时添加源文件；所以它最终会成为阻碍。
• 在针对不同框架的项目中链接源文件会导致另一个问题:无法在不同项目中打开相同的源文件。 VS 会通知你这个事实，然后显示来自另一个项目的已经打开的源文件。这会影响 IntelliSense，尤其是在条件编译时。这不是一个阻碍，但很多时候你会打开一个文件，然后必须关闭它并重新打开它(然后回到你原来的位置)。
• VS2010 上的单元测试必须针对 4.0 框架。所以对其他框架版本的任何测试都必须以非 VS2010 方式进行。我还没有找到好的解决方案；它不会影响 Nito.Linq，因为对 4.0 变体进行单元测试会测试所有代码。

我确实问过 Rx team他们是如何处理这种情况的(他们支持具有相同代码库的 3.5、4.0、SL3 和 SL4)。显然，他们使用自定义内部工具来创建运行时程序集的纯元数据版本，然后将它们组合到包含合并的纯元数据程序集的超集配置文件中。该项目是根据这个超集配置文件构建的，并且完成编译后“重定向”以将项目的配置文件更改为正常配置文件之一。

我简要played around构建了一个与 Rx 团队的工具等效的开源工具，但遇到了太多“文档不足”的问题。这在理论上应该是可行的，但我认为如果没有正确的 Microsoft 内部联系人，这将花费太多时间。