【问题标题】:Team Build: The path 'Path' is already mapped in workspace 'workspace' error even after deleting all workspaces on build agentTeam Build:即使删除了构建代理上的所有工作区,路径“路径”也已映射到工作区“工作区”错误中
【发布时间】:2011-01-20 07:48:08
【问题描述】:

我在排队构建时遇到了这个问题。构建因错误而死

路径 C:\[Path]\Sources 已映射到工作区 [Server Name]。

same as this question。但我已经通过运行以下命令删除了构建代理上的所有工作区:

tf workspaces /remove:*

还可以删除 TFS 缓存文件夹。我也重新启动了服务器,但每次构建时都会出现错误。

【问题讨论】:

  • 我很确定上面的命令行只会删除当前用户的工作空间,所以仍然可能有一个工作空间与映射相同路径的另一个用户(在该机器上)相关联.您可以使用 TFS Sidekicks 轻松查看与给定客户端计算机关联的所有工作区。 (对不起,如果我教你吸鸡蛋!)

标签: tfsbuild tfs workspace


【解决方案1】:

好的,所以最终解决方案与YahooStu posted on here 非常相似。我从

更改了 Build Agent 的工作目录
$(Temp)\UI\$(BuildDefinitionPath)

$(Temp)\UI\$(BuildDefinitionPath)\$(BuildDefinitionID)

奇怪的是,我们拥有的另一个构建代理仍在$(Temp)\UI\$(BuildDefinitionPath) 中运行并且工作正常。两个代理之间的唯一区别是停止工作的那个安装了 Visual Studio 2010 RC,而仍在工作的那个安装了 VS2010 Beta2。不知道为什么这会有所作为。

【讨论】:

  • 这对我有帮助。我在构建代理上安装了 VS2010 Ultimate (RTM),然后我们的构建立即开始失败。谢谢!
【解决方案2】:

我认为只有在一个构建盒上有多个构建代理时才会出现此问题。

【讨论】:

  • 我有 3 个代理分配给 1 个控制器。您认为这可能是问题所在吗?
  • 这确实是我的问题。我将我的两个构建代理设置为使用单独的工作副本,然后它就消失了。
【解决方案3】:

http://blog.devaffair.com/2011/11/path-is-already-mapped-in-workspace.html

好吧,实际上这个问题已经在这个网站的其他几个问题中得到了解决,但我会再次发布我的答案:)

此链接将引导您到一个可能会最快解决您的问题的博客

【讨论】:

  • 链接已损坏... :(
  • 链接断开。为了将来参考,请在您的答案中列出步骤,而不是链接到某天会死的博客。
【解决方案4】:

我认为您的问题可能与 3 个未标记的构建代理有关。我认为工作区(如果留下)会被正在构建的代理删除。如果它与创建工作区的代理不同,那么就会出现明显的问题。

因此,要解决此问题,您需要执行以下操作。 将一位代理命名为默认代理。这将没有标签。 在另外两个代理中,在属性中为代理添加一个标签,每个代理一个标签并选择它。

现在执行的任何未设置标记的构建都将始终使用默认代理。

要让构建使用其他代理之一,请打开构建定义并转到流程中的高级部分。

打开代理设置并在标签过滤器中选择省略号,然后为要使用的构建代理上输入的标签输入同名标签。

您可能需要在第一次运行之前清理工作区。

执行上述操作可让您控制每个构建定义使用的构建代理,因此也应该停止您的工作区问题。

【讨论】:

    【解决方案5】:

    我能够删除工作区。 在构建服务器上执行此操作:

    从 sysinternals 下载 psExec。
    http://technet.microsoft.com/en-us/sysinternals/bb897553

    以管理员身份打开 cmd。

    运行 psexec 以将 cmd 作为网络服务打开。
    psexec -i -u "nt 权限\网络服务" cmd.exe 这将打开另一个“nt authority\network service”正在使用的 cmd 窗口。

    运行“whoami”以确保您现在是“nt authority\network service”。

    输入 devenv 打开 Visual Studio。

    在visual studio\team explorer中,连接到源代码管理服务器

    在 Visual Studio\源代码管理资源管理器中,丢弃有问题的工作区。

    我不知道为什么,但 tf 工作区 /remove 对我不起作用。

    【讨论】:

    • 这是最好的解决方案。
    【解决方案6】:

    更多关于工作目录属性的信息在这里:

    http://msdn.microsoft.com/en-us/library/bb399135.aspx

    但是,在 RTM 版本中,“$(HOMEDRIVE)”无法识别。可能是因为外壳;尚未对其进行测试,因此请注意文档中的该缺陷。

    【讨论】:

      【解决方案7】:

      我遇到了同样的问题 - 在我在构建代理上安装 VS2010 之前它运行良好。添加 BuildDefinitionId 修复了它,但奇怪的是安装 VS2010 会弄乱已经设置和运行的工作空间。

      【讨论】:

        【解决方案8】:

        改为

        $(Temp)\UI\$(BuildDefinitionPath)\$(BuildDefinitionID)

        使其工作,但不适用于 100% 的情况。每次构建无法完成时(例如源代码中的一些错误或其他东西),然后在修复错误并尝试再次运行团队构建后,它会在“工作区 XYZ 已映射 ...”上失败,然后我必须手动删除它“Team Foundation Sidekick 2010”的工作区映射并再次运行团队构建以取得成功。下一次多次执行同一个团队构建成功构建,但直到某个团队构建由于源代码中的某些错误而失败,然后它再次开始抛出“工作空间映射”错误。

        在我看来,TFS 2010 在某些团队构建失败时存在一些错误,它不会清除/删除使用的工作区或类似情况。

        有人遇到同样的问题吗?

        【讨论】:

          【解决方案9】:

          ==== Visual Studio 2010 ====

          我无法在 TFS Sidekick 中看到“故障”工作区,因此无法删除它们。 大卫奥斯本描述的步骤为我指明了正确的方向。我能够在 TFS Sidekick 中看到“有问题”的工作区,最后我可以删除它们。

          On the build server do this:
          
          Download psExec from sysinternals.
          http://technet.microsoft.com/en-us/sysinternals/bb897553
          
          Open cmd as Administrator.
          
          Run psexec to open cmd as Network Service.
          psexec -i -u "nt authority\network service" cmd.exe That opens another cmd window that "nt authority\network service" is using.
          
          Run a “whoami” to make sure you’re now "nt authority\network service".
          
          Open visual studio by typing C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.
          
          When asked use the login from the TFS buildagent account to start Visual Studio.
          
          Within visual studio\team explorer, Connect to the source control server
          
          Within visual studio\ source control explorer, throw away the offending workspaces.
          
          Delete the "faulty" workspaces with TFS SideKick.
          

          现在问题解决了。

          【讨论】:

            猜你喜欢
            • 2010-09-18
            • 2015-06-20
            • 2016-01-23
            • 2012-04-19
            • 1970-01-01
            • 2016-05-06
            • 1970-01-01
            • 2010-10-18
            • 2015-12-12
            相关资源
            最近更新 更多