我们有一个带有两个分支的TFS 2008项目（“Main”和“NewFeature”）。 每个都是源代码的完整，独立的“副本”（变体）。
通过更改工作区映射，我们可以将任一变体映射到我们的本地PC上，并且一直在使用这两个分支，没有任何问题。
但是，如果我设置映射以将我们的构建服务器切换到NewFeature分支（它应该简单地交换NewFeature源代码，而不考虑构建服务器的任何其他内容）我得到错误：
There is no working folder mapping for $/Main/Product.sln
即。当它从NewFeature分支构建时，仍然会在 Main 分支中查找某些内容，即使此分支的源代码中没有任何引用。它似乎缓存了对Main的一些引用？！
我做了一个完全干净的构建（从服务器删除了构建文件夹并使用/ p：ForceGet = true运行构建以确保映射被刷新到服务器，并且服务器上没有文件可能会缓存工作区绑定），但这没有帮助。
有什么建议吗？
答案 0 :(得分：9)
验证：
/ EDIT /
但是，请注意，$ / Main和$ / Branches / Feature位于树层次结构中的同一级别，不重要。构建服务器上的本地路径也不应该重要。*所有重要的是每个分支下面的内容。如果内容内部一致，则所有现有构建脚本都应该无需修改即可运行。
有关我如何将所有内容组合在一起的具体示例，请参阅我过去的答案，例如：
我的方式不是唯一的方法，但我可以证明它比我多年来遇到的所有其他变化都更好：）
*坦率地说，尝试对Team Build进行微观管理会比建议的MSBuild脚本重组更加痛苦。为了确保可靠性，您必须将tfsbuildservice.exe.config customizations置于版本控制之下...如果您拥有＆gt; 1构建服务器（或将来可能），那么您必须考虑更改部署策略...您最终需要用于管理SCM流程的元SCM流程！
答案 1 :(得分：9)
我在TFS 2010中从分支运行构建时也遇到此问题.TFS报告“$ / Main / Product.sln没有工作文件夹映射”解决方案原来是编辑构建定义如下（我正在使用“默认模板”构建过程模板 - 我没有尝试使用自定义模板）：
答案 2 :(得分：3)
好的，结果是 - 我找到了解决方法。
由于我们的遗留构建流程（构建，复制，混淆，构建自定义安装程序，复制到drop文件夹），我无法轻松地将分支与一起放在主分支中。它需要替换它。
所以，如果我有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分支机构？如何在分支机构之间切换开发人员？如何在分支机构之间切换服务器构建？真的必须这么痛苦吗？
答案 3 :(得分：2)
编辑构建定义时，有两个地方需要更改。
希望这会有所帮助。
答案 4 :(得分：0)
新更新：
正如在另一个答案中所报告的那样，我找到了一个对于短期功能分支来说可行的解决方法，但它确实不能很好地工作。我已经回到这个问题，完整的解决方案非常简单：
在TFSBuild.proj中，路径基于$（BuildProjectFolderPath）。此路径解析为服务器端（源控制路径），如$ / Main - 不是本地路径（D：\ ServerBuildFolder \ Main）。
不幸的是，由于历史原因，我们的源代码被分成几个团队项目，这意味着一个“分支”被分割成源代码管理中的几个分支文件夹（即$ / Main / Code和$ / Libraries / Code。你可以不要创建一个包含$ / Main和$ / Libraries的分支。因此，我们必须使用工作空间映射将源控制中的这些不同片段重新组合成一个连贯的层次结构。
这意味着理查德的位置 - 从TFSBuild.proj文件到.sln文件的相对路径不正确，因为MSBuild / TFS假设.sln位于同一个团队项目和源代码控制层次结构中（所以正在寻找$ / Main / Libraries.sln而不是$ / Libraries / Libraries.sln。
解决方案很简单：我将$（BuildProjectFolderPath）替换为文件的本地路径（例如D：\ ServerBuildFolder \ Main），以便在“局部空间”中解析相对引用（在应用映射之后） ），MSBuild现在正在甜蜜地运行。
故事的寓意： 1）如果您有可能希望在这些代码库之间有任何参考，请不要使用多个团队项目。不要误以为新的团队项目将在应用程序/库之间提供某种无痛的逻辑区别。事实证明，额外的项目只是一场政府的噩梦 - 额外的问题是绝对零利益。 （这是发动机罩下的所有大型共享堆，因此所有工作项和源控制文件夹在所有项目中仍然可见（！），但它增加了一些砖墙，使项目间链接非常有问题）
2）始终在Team Project源代码管理中创建一个根级文件夹，然后将其他所有内容放在该文件夹下。例如对于项目“$ / Main”，创建“$ / Main / Root”，然后将源层次结构中的所有内容放在Root中。
通过遵循这些规则，您将来可以分支单个“Root”文件夹，然后只需要一个分支和一个额外的工作区映射。这将有助于避免过早秃发。
（在我的辩护中，我会以这种方式开始 - 我正在使用传统设置。为了保护传统设置，它在纸面上听起来不错，但不是微软支持的方法！）
答案 5 :(得分：0)
我收到了这个错误，我所能理解的是定义变得腐败或其他什么。我只是重做了进程的东西（重新添加了我试图构建的解决方案）并重新映射了工作区，它又重新开始工作了。 HTH。