用于定位多个.NET版本的构建系统

Question

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

特别:

• 你应该在源代码控制中分支吗？
• 你应该使用条件编译吗？
• 你应该派生接口,从而对它们进行版本化吗？
• 你应该创建单独的"versionX"项目并链接常见的项目文件吗？

Answer 1

我尝试过几种不同的方法.

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

我使用条件编译以及使用链接源文件的特定于版本的项目.我在这些方面做过的最积极的图书馆是Nito.Linq,尚未发布.但是,您可以查看源代码,了解我如何设置项目.它目前针对 3.5,4.0,SL3和SL4,并且每种都具有"带Rx"和"无Rx"变体.我也有CF 3.5工作,但VS2010不支持它.

这种方法有一些缺点:

• 在我的解决方案中,我定义了一个"Sources"项目,它充当文件的容器.不幸的是,它是在加载时构建的,当它被卸载时我无法添加源文件; 所以它最终会挡路.
• 链接目标不同框架的项目中的源文件会导致另一个问题:不可能在不同的项目中打开相同的源文件.VS会告知您这个事实,然后显示另一个项目中已经打开的源文件.这会影响IntelliSense,尤其是条件编译.不是一个显示阻止,但很多时候你会打开一个文件,然后必须关闭它并重新打开它(然后回到你所在的位置).
• VS2010的单元测试必须以4.0框架为目标.因此,对其他框架版本的任何测试都必须以非VS2010方式完成.我还没有找到一个好的解决方案; 它不会影响Nito.Linq,因为测试4.0变体的单元测试所有代码.

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

我简单地介绍了构建Rx团队工具的开源等效工具,但遇到了太多"未被记录的"障碍.理论上它应该是可能的,但我认为对于没有Microsoft内部正确联系人的人来说,这将花费太多时间.