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

Question

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

具体做法是：

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

Answer 1

我尝试了几种不同的方法。

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

我使用条件编译以及使用链接源文件的特定于版本的项目。我在这些方面做过的最具侵略性的库是Nito.Linq，尚未发布。但是，您可以查看源代码，了解我如何设置项目。它currently targets 3.5,4.0，SL3和SL4，并且每个都具有“with Rx”和“without 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内部正确联系人的人来说，这将花费太多时间。