TFSBuild/MSBuild 和项目参考与文件参考
我们有一个使用由 TFS Build 构建的项目引用的大型 VS 解决方案，如下所示：
Solution
- Project 1
- Project 2
- Project ...
- Project N
因为该解决方案太大，所以我们有几个日常使用的较小解决方案：
SubSolution
- Project 1
- Project 19
问题是从事 SubSolution 的开发人员发现它没有构建因为找不到项目引用，所以他们将项目更改为使用文件引用。
然后，这会继续破坏 TFS 构建，它无法找到这些文件引用，因为它们尚未构建（即使项目位于同一解决方案中）。有没有办法解决这两种类型的引用之间的拉锯战？分解解决方案的正确方法是什么？
We Have a large VS solution using project references which is build by TFS Build like so:
Solution
- Project 1
- Project 2
- Project ...
- Project N
Because the solution is too large we have several smaller solutions which we use day to day:
SubSolution
- Project 1
- Project 19
The problem is that developers working on SubSolution find that it is not building because the project references could not be found, so they change the projects to use file references.
This then goes on to break the TFS Build which cannot find these file references because they have not been built yet (Even though the projects are in the same solution). Is there a way around this tug of war between the two types of references. What is the correct way of splitting out your solutions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
请查看 Patterns & 的 TFS 指南中的本章。实践团队：
第 3 章 - 在源代码管理中构建项目和解决方案
请特别注意“分区解决方案”场景（我相信您实际上正在尝试实现）的注释：
Check out this chapter from the TFS guide by the Patterns & Practices team:
Chapter 3 - Structuring Projects and Solutions in Source Control
Pay special attention to this note to the "Partitioned Solution" scenario (which I believe you're actually trying to implement):
无论您如何组织构建，开发人员都应该了解引用的工作方式，并在对引用进行更改时注意，他们不应该检查这些更改除非他们打算进行更改到构建过程。
关于组织构建的主题 - 正如 Dmytrol 所说，项目引用应该在解决方案之间工作（只要目标已经构建，但无论如何文件引用也是如此）。
我的建议是将您的项目分组为小型可行的解决方案，并在这些解决方案中使用项目参考。您的主解决方案文件/构建也可以使用项目引用，但是，如果您发现较小解决方案之间的项目引用太难维护，您可以使用文件引用来代替，并通过项目依赖项或项目构建顺序（可在 Visual 中访问）来控制构建顺序Studio，方法是右键单击解决方案中的项目）。
Regardless of how you organise your build, developers should understand how references work, and be aware when they make changes to references that they shouldn't check those changes in unless they intended to make a change to the build process.
On the subject of organising your builds - as Dmytrol says, project references should work between solutions (As long as the target is already built, however that's also the case for file references anyway).
My advice would be to group your projects into small workable solutions and use project references within those solutions. Your main solution file / build can use project references too, however if you find project references between the smaller solutions too difficult to maintain you can use file references instead, and control the build order through project dependencies or the project build order (accessible within Visual Studio by right-clicking on a project in your solution).