Team Build: The path 'Path' is already mapped in workspace 'workspace' error even after deleting all workspaces on build agent

Viewed 28465

I have this problem when I queue a build. The build dies with the error

The path C:\[Path]\Sources is already mapped in workspace [Server Name].

the same as this question. but I've removed all the workspaces on the build agent by running this command:

tf workspaces /remove:*

and also by deleting the TFS cache folder. I've also restarted the server, but the error keeps happening on each build.

9 Answers

Ok, so the solution ended up being fairly similar to what YeahStu posted on here. I changed the Build Agent's working directory from

$(Temp)\UI\$(BuildDefinitionPath)

to

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

What is odd is that the other build agent we have is still running in $(Temp)\UI\$(BuildDefinitionPath) and working fine. The only difference between the two agents is the the one that stopped working had Visual Studio 2010 RC installed on it, while the one that's still working has VS2010 Beta2 on it. No idea why this should make a difference.

I think the issue appear only if you have more then one build agents on one build box.

Changed to

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

makes it working but not for 100% situations. Every time when build failed to complete (e.g. some error in source-codes or something), then after fixing error and trying to run team build again it fails on "Workspace XYZ is already mapped ...", then i must manually delete this workspace mapping by "Team Foundation Sidekick 2010" and run team build again to be success. Next time executing same team build more than once are successfully builded, but until some team build fail according to some error in source code, then it again start to throw "workspace mapping" errors.

It seems to me that TFS 2010 has some bug when some team build fails, it does not clear/delete workspace used, or something similar.

Have someone same problems experiencing?

==== Visual Studio 2010 ====

I wasn't able to see the "faulty" workspaces in TFS Sidekick and thus could not remove them. The steps that David Osborne described pointed me to the right direction. I was able to see the "faulty" workspaces in TFS Sidekick and finally I could remove them.

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.

Now the issue was solved.

Related