TFSBuild/MSBuild 和项目参考与文件参考

Posted 2023-02-15

【中文标题】TFSBuild/MSBuild 和项目参考与文件参考

【英文标题】：TFSBuild/MSBuild and Project Reference vs File Reference

【发布时间】：2011-01-24 01:57:02

【问题描述】：

我们有一个使用由 TFS Build 构建的项目引用的大型 VS 解决方案，如下所示：

Solution
- Project 1
- Project 2
- Project ...
- Project N

由于解决方案太大，我们有几个日常使用的较小解决方案：

SubSolution
- Project 1
- Project 19

问题是开发 SubSolution 的开发人员发现它没有构建，因为找不到项目引用，因此他们将项目更改为使用文件引用。

这会继续破坏 TFS 构建，它无法找到这些文件引用，因为它们尚未构建（即使项目在同一个解决方案中）。有没有办法解决这两种类型的引用之间的拉锯战。拆分解决方案的正确方法是什么？

【问题讨论】：

也许您可以尝试为正在构建的主要子项目添加依赖项 (DependsOn)？

【参考方案1】：

拆分解决方案的正确方法是什么？

查看 Patterns & Practices 团队的 TFS 指南中的这一章：

Chapter 3 - Structuring Projects and Solutions in Source Control

请特别注意“分区解决方案”场景的注释（我相信您实际上正在尝试实施）：

与以前版本的 Visual Studio 不同，Visual Studio 2005 依赖于 MSBuild。现在可以创建不包括所有引用项目并且仍然可以无错误构建的解决方案结构。只要首先构建了主解决方案，从每个项目生成二进制输出，MSBuild 就能够遵循解决方案范围之外的项目引用并成功构建。这仅在您使用项目引用而不是文件引用时才有效。您可以从 Visual Studio 生成命令行和 IDE 成功生成以这种方式创建的解决方案，但默认情况下不能使用 Team Build。为了使用 Team Build 成功构建，请使用包含所有项目和依赖项的主解决方案。

【参考方案2】：

无论您如何组织构建，开发人员都应该了解引用的工作原理，并注意当他们对引用进行更改时，他们不应该检查这些更改，除非他们打算这样做更改构建过程。

关于组织构建的主题 - 正如 Dmytrol 所说，项目引用应该在解决方案之间起作用（只要目标已经构建，但无论如何文件引用也是如此）。

我的建议是将您的项目分组为小型可行的解决方案，并在这些解决方案中使用项目引用。您的主要解决方案文件/构建也可以使用项目引用，但是如果您发现较小解决方案之间的项目引用太难以维护，您可以使用文件引用，并通过项目依赖项或项目构建顺序控制构建顺序（可在 Visual Studio 通过右键单击解决方案中的项目）。