我们有一个 TFS 2008 项目，它有两个分支（“Main”和“NewFeature”）。每个都是源代码的完整、独立的“副本”（变体）。
通过更改工作区映射，我们可以将任一变体映射到我们的本地 PC 上，并且可以毫无问题地使用这两个分支。
但是，如果我设置映射以将我们的构建服务器切换到 NewFeature 分支（就构建服务器而言，它应该简单地交换 NewFeature 源代码而不更改任何其他内容）我得到错误：
There is no working folder mapping for $/Main/Product.sln
即，当它从 NewFeature 分支构建时，仍然在Main分支中查找某些内容，即使在源代码中的任何地方都没有对该分支的引用。它似乎正在缓存对 Main 的一些引用？！
我已经完成了一个完全干净的构建（从服务器中删除了构建文件夹并使用 /p:ForceGet=true 运行构建，以确保映射被刷新到服务器，并且服务器上没有可能缓存的文件工作区绑定），但这无济于事。
有什么建议么？
验证：
/ 编辑 /
但是请注意，$/Main 和 $/Branches/Feature 在树层次结构中位于同一级别并不重要。构建服务器上的本地路径也不重要。*重要的是每个分支下面的内容。如果内容在内部是一致的，那么您现有的所有构建脚本都应该无需修改即可工作。
有关我喜欢如何将所有内容联系在一起的具体示例，请参阅我过去的答案，例如：
我的方式不是唯一的方式，但我可以证明它比我多年来遇到的所有其他变体都更有效:)
*坦率地说，尝试对 Team Build 进行微观管理可能比建议对 MSBuild 脚本进行重组要痛苦得多。为了可靠性，您必须将tfsbuildservice.exe.config 自定义项置于版本控制之下...如果您拥有 >1 个构建服务器（或将来可能），那么您必须考虑更改部署策略...您最终需要一个元 SCM 流程来管理您的 SCM 流程！
从 TFS 2010 中的分支运行构建时，我也遇到了这个问题。TFS 报告“$/Main/Product.sln 没有工作文件夹映射”解决方案结果是编辑构建定义如下（我正在使用“默认模板”构建过程模板——我没有用自定义模板尝试过）：
好的，结果出来了——我找到了一种解决方法。
由于我们遗留的构建过程（构建、复制、混淆、构建自定义安装程序、复制到放置文件夹），我无法轻松地将分支放在主分支旁边。它需要更换它。
所以，如果我有 Main 和 NewFeature，我希望取消映射 Main 并在其位置映射 NewFeature（即在构建服务器上使用“c:\Main”，并简单地更改出现在那里的源代码）
解决方案#1（最简单、最明显和合乎逻辑的解决方案）是使用这些映射：
预期结果：NewFeature 代码结构简单地替换了 Main，并且构建服务器不知道它在不同的分支上。
实际结果：失败并出现“即使您没有使用它，您也没有映射 $/Main”错误。
解决方案 #2是这样做的：
这有效（它抑制了警告，因此允许构建继续进行 MSBuild，而不知道它是在分支中构建的）。但是，它很丑陋，并且构建不必要地获取了所有 Main 分支源代码。
解决方案＃3（未经测试，除非我知道它会比＃2好得多，否则无法尝试）是：
希望我可以只映射到我需要的分支并编辑 TFSBuild.proj 以将其重定向到在该分支中构建。
（编辑：是的，这很好用。我们现在重新组织了整个代码结构，以便所有内容（所有分支）都在单个团队项目中的共同根下，并且分支/构建不再是问题 - 做任何事情都很容易我们现在需要。诀窍是在层次结构中插入一个根文件夹，以便您可以在任何您喜欢的级别进行分支。我在构建脚本中添加了一个小调整，以便我们可以将要构建的分支作为参数传递给MSBuild，所以现在很容易构建任何变体。我们不想处理的任何分支都可以隐藏起来，构建服务器仍然很开心。）
总结 所有这些解决方案（使用技术术语）都很糟糕。您必须重新映射工作区（在这种情况下，这并不简单：需要 9 个映射条目，因此这是一个容易出错且乏味的事情），编辑 TFSBuild.proj，删除所有源代码，然后使用 / 运行构建p:ForceGet=true 在分支之间切换构建。所以切换分支大约需要一个小时。难以置信 - 最多需要几分钟！
我意识到我们的项目远非理想设置，但我不敢相信在 TFS 中分支会如此困难（这在 SourceSafe、Accurev 和 Perforce 中是小菜一碟，为什么在 TFS 中如此痛苦？）。
其他人如何组织他们的 TFS 分支？你如何在分支之间切换开发人员？如何在分支之间切换服务器版本？真的有必要这么痛吗？
当您编辑构建定义时，有两个地方需要更改。
希望这可以帮助。
新更新：
正如另一个答案中所报道的，我找到了一种解决方法，对于一个短暂的功能分支来说是可以的，但它确实不能很好地工作。从那以后我又回到了这个问题上，完整的解决方案非常简单：
在 TFSBuild.proj 中，路径基于 $(BuildProjectFolderPath)。此路径解析为 $/Main 之类的服务器端（源代码控制路径），而不是本地路径 (D:\ServerBuildFolder\Main)。
不幸的是，由于历史原因，我们的源代码被拆分为多个团队项目，这意味着一个“分支”在源代码控制中被分割成多个分支文件夹（即 $/Main/Code 和 $/Libraries/Code。您无法创建包含 $/Main 和 $/Libraries 的分支）。因此，我们必须使用工作区映射将这些不同的片段从源代码控制重新组合成一个连贯的层次结构。
这意味着 Richard 发现了 - 从 TFSBuild.proj 文件到 .sln 文件的相对路径不正确，因为 MSBuild/TFS 假设 .sln 位于相同的团队项目和源代码控制层次结构中（因此正在寻找$/Main/Libraries.sln 而不是 $/Libraries/Libraries.sln)。
解决方案很简单：我将 $(BuildProjectFolderPath) 替换为文件的本地路径（例如 D:\ServerBuildFolder\Main），以便在“本地空间”中解析相对引用（在应用映射之后），并且MSBuild 现在运行良好。
故事的寓意：1) 如果您有任何机会希望在这些代码库之间有任何类型的引用，切勿使用多个团队项目。不要误以为新的团队项目会在应用程序/库之间提供某种无痛的逻辑区分。额外的项目已被证明只是管理方面的噩梦——大量额外的问题绝对是零收益。（在引擎盖下都是一大堆共享文件，所以所有工作项和源代码管理文件夹在所有项目中仍然可见（！），但它增加了一些砖墙，使项目间链接非常有问题）
2) 始终在您的团队项目源代码管理中创建一个根级文件夹，然后将其他所有内容放在该文件夹下。例如，对于项目“$/Main”，创建“$/Main/Root”，然后将源层次结构中的所有内容放入 Root 中。
通过遵循这些规则，您将来可以分支单个“根”文件夹，然后只需要一个分支和一个额外的工作区映射。这将帮助您避免过早秃顶。
（在我的辩护中，我会以这种方式开始 - 我正在使用旧版设置。在为旧版设置辩护时，这在纸上听起来不错，但不是微软支持的方法！）
我得到了这个错误，我所能理解的就是定义被破坏了。我只是重做了流程的东西（重新添加了我试图构建的解决方案）并重新映射了工作区，它又开始工作了。HTH。