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

发布于 2024-09-08 23:27:31 字数 196 浏览 2 评论 0原文

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

具体来说：

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

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

南街女流氓 2024-09-15 23:27:31

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

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

我使用条件编译以及使用链接源文件的特定于版本的项目。我在这些方面所做的最激进的库是 Nito.Linq，它尚未发布。不过，您可以查看源代码，了解我是如何设置项目的。它当前目标 3.5、4.0、SL3 和 SL4，并且具有“with 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 团队的开源版本相当的项目工具，但遇到了太多“记录不足”的障碍。理论上这是可能的，但我认为对于没有微软内部正确联系的人来说这会花费太多时间。

I've tried a few different ways of doing this.

I ruled out branching because it's a bit difficult to keep all the branches in sync using SVN/TFS. Distributed SCC does have more advanced support for branching/merging, so I'm planning to reconsider this approach if I ever convert.

I use conditional compilation along with version-specific projects using linked source files. The most aggressive library I've done along these lines is Nito.Linq, which hasn't been released yet. You can check out the source, though, to see how I've set up the projects. It currently targets 3.5, 4.0, SL3, and SL4, and has "with Rx" and "without Rx" variants for each of these. I had CF 3.5 working as well, but VS2010 doesn't support it.

There are a few drawbacks to this approach:

In my solution, I defined a "Sources" project that acts as a container for the files. Unfortunately, it's built when loaded and I can't add source files when it's unloaded; so it ends up getting in the way.
Linking the source files in projects targeting different frameworks causes another problem: it's not possible to open the same source file in different projects. VS will inform you of the fact and then show the already-open source file from another project. This affects IntelliSense, especially with the conditional compilation. Not a show-stopper, but many times you'll open a file and then have to close it and re-open it (and then go back to the position where you were).
Unit tests on VS2010 have to target the 4.0 framework. So any testing on other framework versions has to be done in a non-VS2010 way. I haven't found a good solution for this yet; it doesn't affect Nito.Linq because unit testing the 4.0 variants tests all the code.

I did ask the Rx team how they handled this situation (they support 3.5, 4.0, SL3, and SL4 with the same codebase). Apparently, they use a custom in-house tool to create metadata-only versions of the runtime assemblies and then combine these into a superset-profile containing the merged metadata-only assemblies. The project is built against this superset-profile and a post-compilation "retargeting" is done to change the project's profile to one of the normal profiles.

I briefly played around with building an open-source equivalent of the Rx team's tool, but ran into too many "underdocumented" snags. It should be possible in theory, but I figured it would take way too much time for anyone without the correct contacts inside Microsoft.

回复收藏 0 原文

~没有更多了~