How to handle "The path X is already mapped in workspace Y"

This has come up before on the forums, but I don't think I've ever posted about it here.  Today I saw a reference to the TFS Workspace Gotcha! post in today's Team System Rocks VSTS Links roundup.  There's a command to deal with the problem, but it's not obvious.

Here's the post.

I have been working with a team that has recently migrated a TFS source project from a trail TFS to a full production server (different server).  They disconnected their solution from source control (removes all the SCC stuff from .sln) files and then tried to add to the new TFS.

However, they were getting weird errors.

I suggested that they might not have their workspace mapped correctly to the new TFS project.

When they tried to map the workspace, they got the following error:

The Path <local path> is already mapped in workspace <machine name [old tfs server]>

Hmm, I thought we removed all the source stuff?

Turns out that the workspace mappings are stored in a file called:

VersionControl.config under the users local settings/application data directory.

I could find no way (other than manually editing the forementioned file) to remove the workspace mapping from that local folder to the other TFS server (which is no longer in usage).

Anyway, once that was done, all was good in the world.

Thanks go out to Kevin Jones for his excellent post on Workspaces in TFS.

While deleting versioncontrol.config will clear the cache, we've actually got a way to do it from the command line.  The command "tf workspaces /remove:*" clears out all of the cached workspaces (it only affects the cache file).  You can also specify "/s:http://oldserver:8080" to clear out only the workspaces that were on the old server. The MSDN documentation for the workspaces command is at

The reason that he hit this is due to switching servers. Every server has a unique identifier, which is a GUID. Each local path can only be mapped in a single workspace, and the versioncontrol.config cache file is the file that the client uses to determine what server to use when given a local path (e.g., tf edit c:projectsBigAppfoo.cs).

He originally had a workspace on the old server that used the local path he wanted to use with the new server. Let's say that's c:projects. When he tried to create the new workspace on the new server (GUID2) that he also wanted to map to c:projects, the client saw that the old server (GUID1) was already using that local path. Since the IDs for the servers did not match, the client complained that c:projects is already mapped to the old workspace on the old server.

The client uses the server's ID as the real name of a server.  The reason is that the name could change, either because an admin changed the server's name or because a user needs to access the server through a different name depending on the connection (intranet vs. internet).  The only "name" guaranteed not to change is the ID.  So, when presented with a different network name, the client requests the ID from the server and compares it to the IDs listed in the versioncontrol.config cache file.  If the ID matches one of them, the client simply updates the existing entry to have the new name, so that subsequent uses of the new name do not incur an extra request to check the ID.  If the ID does not match any of them, then the server is different than any of the servers in the cache file.

The error message looks like it's showing the machine, but it's actually showing the workspace name.  The reason for the confusion there is that the version control integration in VS creates a default workspace that has the same name as the machine.

The problem will not occur if you upgrade the same server (i.e., you don't create a new server), as an upgraded server still has the same ID.

Though /remove isn't mentioned (part 2 does mention the error message at the end), you can check out Mickey Gousset's workspace articles for more information on workspaces and managing them.

tags: , ,

Comments (30)

  1. 過去幾個月,零零星星的聽見到 某些正在使用 TFS 與 TE 的團隊 提到,  Workspace Mapping 好像怪怪的,常常會有問題 明明對應好了,好像會跑掉 東西放不完整… 這個 抱怨就進階的…

  2. Andy Johns on Bye Bye TFS.

    Rob Caron on Team Foundation Server Language Change Package.

    Aaron Hallberg…

  3. On the Microsoft forums , that is…no, I didn’t suddenly eclipse Raymond . As you probably haven’t noticed,

  4. pb says:

    But this doesn’t help when trying to remove the temporary workspaces TFS creates during the build. I have a temporary workspace that has been left "hanging" and can’t get rid of it.

  5. buckh says:

    pb, you’ll want to run tf workspaces /owner:<whatever your build service account is> /computer:* to get a list of the workspaces.  You can then delete it with tf workspace /delete:workspaceName;workspaceOnwer.


  6. David Quinlan says:


    I am getting this error also, but I’m not sure it is for the same reason.

    Our projects share our core frame work solutions.

    So DevPathA will have a build configured and reference Source Control for main solutions and frame work solutions, DevPathB will have build configured and reference source control for it’s branch of solutions and the same framework solutions.

    When we run build on DevBathB, we receive the error.

    Basically, 2 builds on 2 different branches of source, referencing the same set of shared sources.

    Any ideas?



  7. buckh says:

    David, that should be fine, but you will need to make sure that the local paths for the workspace mappings in each of the build definitions do not overlap. They can both map the same thing from version control, but they cannot use the same local path (i.e., they each need their own independent local copy).

    If you’ve had to rename or re-arrange builds, it could be that you need to delete the old build workspaces to make way for the new ones.  You can use the tf workspace /delete command.  The form would be tf workspace /delete workspaceName;workspaceOwner /s:http://yourserver:8080, which an admin could do.  Or you could log in as the build service account and delete the workspace(s) with the tf workspace /delete command without needing to be admin.


  8. David Quinlan says:

    Cheers Buck,

    What about having 2 builds for the same branch, one that deploys to a DEV server on a daily basis, the other, that deploys to a TEST server on demand (or weekly).


  9. buckh says:

    David, that should work very well.  We do this internally, for example, where we have CI and nightly builds for the same branch.

    As long as you keep the local paths in the workspace mappings disjoint, you should be good.


  10. Anton de Gruchy says:

    I have removed all references in Version.config for both VS 2005 and VS 2008 and I have deleted the workspace using fs workspace command utility. Yet I still have the problem. They changed our domain name and the old domain is in the "workspace" but I cannot seem to find out where to delete it.

  11. buckh says:

    Anton, did you clone a server?  If so, that can cause issues.  Changing the domain name won’t confuse the client.


  12. Srikanth says:

    Running "tf workspaces /remove:*" from VS command prompt helped me fix the error.

    I also had to reboot the VS IDE and removed the old workspace and created a new one and everything started working.

    Thank you !

  13. Anitha says:

    Hi Buck,

    I get this same error for my workflow. But the thing I can’t unserstand here is that I got the same error when I tried to create a workflow on a different build machine. If I am trying to run it on the same machine then the ID will be cached in the temp cache, but how is it possible that it conflicts with a different build machine??


  14. Omar Damiani says:

    Hey! good tip! you saved my day(s)!!!!


  15. buckh says:

    Anitha, the default workspace name in TFS Build 2008 was $(COMPUTERNAME)_$(BuildDefinitionId), and in TFS Build 2010 it is $(BuildDefinitionId)_$(BuildAgentId)_$(ServiceHostName).  In both versions this is overridable, so be sure to check that someone didn’t override it and set it to a hard-coded value or something.


  16. Paul C. says:

    mapping each server to it’s own individual folder will solve this issue.

  17. Dave M. says:

    Works a treat! Thanks.

  18. Gabriel Rodriguez says:

    saved me a lot of time. Thanks a lot for the post Buck!

  19. Elad Shalom says:…/path-is-already-mapped-in-workspace.html

    This is what I found to handle this exception

  20. bob says:

    TFS guys- Let's get our act together- I shouldn't have to resort to finding out where a cache is, or running a cmd line program, or googling the error until I stumble across a blog with the answer.

  21. Peter A Anania says:

    FYI – In Win 7 its C:Users,yourUserName>LocalMicrosoftTeam Foundation3.0Cache

  22. Kerry Millen says:

    You have stated with just a few words the sum of my experience with TFS, "but it's not obvious". Thanks for the great post. Incidentally, even if I'm not a novice, why can't more actions in TFS be obvious?

  23. Chris Wright says:

    I completely removed the workspace entries from that config file and all VersionControl.config files on my system and as soon as you open Visual Studio, it writes new entries into that file. So removing those entries is futile. They must be getting cached on the server as well somewhere because I keep getting that same error, not matter what I do. Even if I remove all my workspaces from Visual Studio, remove all the entries in those config files, I still get the same error that I can't map a certain folder because it was mapped before.

  24. buckh says:

    Chris, the best approach would be to let the cache get populated and then compare when it has vs. what you get back in the error message to figure out which servers are involved and which workspaces on those servers. Then one of those workspaces needs to be changed.

  25. Senthil K Ranganathan says:

    Simplest way to do this is to go to your AppData and delete the TFS cache (depending on the version 3.0 or 4.0)

    C:Users{UserName}AppDataLocalMicrosoftTeam Foundation3.0Cache


    C:Users{UserName}AppDataLocalMicrosoftTeam Foundation4.0Cache

  26. Craig Gordon says:

    This worked great for me when I was running TFS 2010 but now I am have the same error with TFS2013 and this doesn't resolve my issue anymore.  I'm not sure if this relates local or server workspaces or there handled differently but when run this it cause other issue and I have to remove and recreate the workspace all over again.

    Any help would be great.

  27. Taylor Lafrinere says:

    @Craig We'd be happy to help we just need to know more about your scenario.  Can you reach out to me at so that we can chat about this over email.



  28. Craig Gordon says:

    Taylor and John I want to thank you both for the help you provided, I am posting the results here incase someone else runs into the issue:

       tf workspaces /remove

             (will remove the cached workspace info from the local machine. Thus, we need)

       tf workspaces /collection:—- /login:—-

            ( to repopulate the cache (and also print the information to stdout), so that)

       tf workfold [args]

            (will know what workspaces are available to work in.)

    The second command here is what fixed the problem for my work.

  29. Ashok Kumar says:


    If you write some blog, then it should be understandable for others to understand. Otherwise I would say, it is waste of readers time only.

    See the below link with the top answer, how simple it is!…/team-build-error-the-path-is-already-mapped-to-workspace

  30. Don says:

    Thanks so much for this. An almost instant solution to my problem!

Skip to main content