分支的 TFS 构建服务器构建？

Question

我们有一个 TFS 2008 项目，它有两个分支(“Main”和“NewFeature”)。
每个都是源代码的完整、独立的“副本”(变体)。

通过更改工作区映射，我们可以将任一变体映射到我们的本地 PC 上，并且可以毫无问题地使用这两个分支。

但是，如果我设置映射以将我们的构建服务器切换到 NewFeature 分支(就构建服务器而言，它应该简单地交换 NewFeature 源代码而不更改任何其他内容)我得到错误:

There is no working folder mapping for $/Main/Product.sln

即，当它从 NewFeature 分支构建时， 中仍在寻找某些东西。主页 分支，即使源代码中的任何地方都没有对此分支的引用。它似乎正在缓存对 Main 的一些引用？!

我已经完成了一个完全干净的构建(从服务器中删除了构建文件夹并使用/p:ForceGet=true 运行构建以确保映射已刷新到服务器，并且服务器上没有可能缓存的文件工作区绑定(bind))，但这无济于事。

有什么建议么？

Answer 1

验证:

$(SolutionToBuild) 在引用 Product.sln

时使用相对路径

$/NewFeature/.../TFSBuild.proj 和 $/NewFeature/Product.sln 之间的相对路径与 Main 分支中的相对路径相同。

/编辑/

但是请注意，$/Main 和 $/Branches/Feature 在树层次结构中位于同一级别并不重要。构建服务器上的本地路径也不重要。*重要的是每个分支下面的内容。如果内容在内部是一致的，那么您现有的所有构建脚本都应该无需修改即可工作。

有关我喜欢如何将所有内容联系在一起的具体示例，请参阅我过去的答案，例如:

Modular TeamBuilds

SDLC Mangement for TFS Build Scripts

Where to put my database project in TFS?

How do you share external dependencies between Visual Studio solutions?

我的方式不是唯一的方式，但我可以证明它比我多年来遇到的所有其他变体都更有效:)

*坦率地说，尝试对 Team Build 进行微观管理可能比建议对 MSBuild 脚本进行重组要痛苦得多。为了可靠性，您必须将您的 tfsbuildservice.exe.config customizations在某个地方的版本控制下...如果您拥有>1个构建服务器(或将来可能)，那么您必须考虑更改部署策略...您最终需要一个元SCM流程来管理您的SCM流程!