[tfs] Team Build Error: The Path ... is already mapped to workspace

When creating a new build in Team Foundation Server, I get the following error when attempting to run the new build:

The path C:\Build\ProductReleases\FullBuildv5.4.2x\Sources is already mapped to workspace BuildServer_23.

I am unable to see a workspace by that name in the workspaces dialog.

I received this error, which was caused by having two build definitions that pointed to the same source. The issue was that I used a static build directory in the Build Agent.

This forum post describes my issue and resolution exactly: http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/60a4138a-9b28-4c46-bdf4-f9775ce43c3e/

We had the same problem but deleting the workspace's from the TFS server did not work. (I should mention that I grabbed my colleagues VM that was already set up with his credentials.)

For me this worked: http://blogs.msdn.com/b/buckh/archive/2006/09/12/path-is-already-mapped-in-workspace.aspx

I just went into the : ...\Local Settings\Application Data\ made a search for VersionControl.config, opened up the folder that contained this file and deleted all of it's contents.

Previous to that I tried manually editing the file but it continued with the same error message.

I hope this helps.

I had this issue with this with Azure DevOps automated builds in an on-prem TFS build agent. Removing the workspace using TFS Sidekicks did not work. And tf.exe could not even find the workspace to delete it.

This solution should work for TFS 2017, TFS 2018, Azure DevOps, and possibly other versions:

1. Take note of the workspace GUID in the error message.
2. On the machine where the build is taking place, navigate to: %USERPROFILE%\AppData\Local\Microsoft\Team Foundation\ (where %USERPROFILE% belongs to the user that triggered the build).
3. Search for and remove all instances of the workspace GUID under that directory. There will likely be a folder in a 'cache' directory, as well as entries in 'LocationServerMap.xml' and 'LocalItemExclusions.config'. Remove them all.

That worked in my circumstance.

For some reason I was having trouble deleting the workspace from the command-line utility. Luckily I found Team Foundation Sidekicks 2010 (from this post) which is free and provides a GUI for viewing and deleting TFS workspaces, and many more useful TFS features.

If you don't have permissions on the server to delete other people's workspaces, you can just change the name of the build definition. TFS will create a new workspace and map it to "C:\Build\ProductReleases\new build name here\Sources".

TDN's solution worked for me when I was having the same issue. The Build server created workspaces under my account. Checking this box allowed me to see and delete them.

Here is what I did (well what I do):

Using TFS Sidekicks clear out the user and server filters so they are blank. This will let you get all workspaces.

Check the build error for the workspace name. In the OPs case it is BuildServer_23. It is different in my environment but basically just match up the error name with the one in the tfs sidekick list.

Click the red x to delete the workspace.

Viola!

My issue was related to using multiple accounts. This is how I was able to switch accounts.

Open Team Explorer

From the big drop down menu near the top of the pane...

Navigate to: Projects and my Teams>Manage Connections

Navigate to: Manage Connections>Connect to Team Project

Use the "Switch User" link to switch accounts.

Now the workspace names will match the chosen account.

I changed

Build Definition -> Workspace -> Build Agent Folder

from

c:\some\path

to

$(SourceDir)

and it fixed the issue.

Simply delete the workspace:

workspace /delete "the-workspace-name"

If applicable, you can also clone the build definition and change its name. This workded for me.

I couldn't get any other solution to work.

I had a new account created and the old account no longer had permissions (both on same machine).

I tried: 1) Deleting the workspace (couldn't see in VS with or without remote workspaces checked) 2) Deleting from the command line 3) New owner command 4) Deleting the cache

So I simply opened VS as admin and mapped to a different folder.

I received this error, which was caused by having two build definitions that pointed to the same source. The issue was that I used a static build directory in the Build Agent.

This forum post describes my issue and resolution exactly: http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/60a4138a-9b28-4c46-bdf4-f9775ce43c3e/

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}\AppData\Local\Microsoft\Team Foundation\3.0\Cache or C:\Users{UserName}\AppData\Local\Microsoft\Team Foundation\4.0\Cache

Just delete the contents of the following folder(s):

C:\Users\UserName\AppData\Local\Microsoft\Team Foundation\3.0\Cache

Where UserName is actual or current user, and 3.0 is the version number.

I had a similar problem with Visual Studio 2010 complaining about an already-mapped-workspace, but instead of deleting the entire workspace, I used the following from the Visual Studio Command Prompt: "tf workspace PROBLEM_WORKSPACE_NAME". This brought up an "Edit Workspace" dialog. From there I was able to remove the path in question from the "Working Folders" list, which got rid of the error.

I changed

Build Definition -> Workspace -> Build Agent Folder

from

c:\some\path

to

$(SourceDir)

and it fixed the issue.

I tried all the following solutions such as :

1. Use sidekicks to delete WS.
2. Use tf commands to delete remote server workspaces.
3. Delete the TFS cache folder.

The following worked for me:

tf workspaces /remove:*

the rest was fairly easy.

Simply go to this folder: C:\Users{UserName}\AppData\Local\Microsoft\Team Foundation\4\Cache and delete all that's in the folder.

I received this error, which was caused by having two build definitions that pointed to the same source. The issue was that I used a static build directory in the Build Agent.

This forum post describes my issue and resolution exactly: http://social.msdn.microsoft.com/Forums/en-US/tfsbuild/thread/60a4138a-9b28-4c46-bdf4-f9775ce43c3e/

the rest was fairly easy.

Simply go to this folder: C:\Users{UserName}\AppData\Local\Microsoft\Team Foundation\4\Cache and delete all that's in the folder.

I had a similar issue and to remove the workspace that was causing me a problem, I logged into another machine with TFS client installed and performed the following:

• On the File menu, point to Source Control, Advanced, and then click Workspaces....
• In the Manage Workspaces dialog box, tick the Show remote packages checkbox.
• Under the Name column, select the workspace that you want to remove, and then click Remove.
• In the Confirmation dialog box, click OK.

I got same issue in Visual Studio 2017 and TFS 2017. DefaultCollection must be mapped first to you local path. Somehow this step was skipped and I got only MyFirstProject mapped.

All you need to do is:
- 1. Go to your TFS web page and remove the project from the server.

- 2. Remove the project from your local "Worksapces"

- 3. Go to "Manage Connections" which will refresh your Home page in TeamExplorer.

- 4. You will get Configuration page which will allow you to setup root path to your DefaultCollection.

- 5. You should get message that it been done successfully. Now you can create your project.

It's important to map root of your collection to your workspace first and then map a new project.

For some reason I was having trouble deleting the workspace from the command-line utility. Luckily I found Team Foundation Sidekicks 2010 (from this post) which is free and provides a GUI for viewing and deleting TFS workspaces, and many more useful TFS features.

I tried all the following solutions such as :

1. Use sidekicks to delete WS.
2. Use tf commands to delete remote server workspaces.
3. Delete the TFS cache folder.

The following worked for me:

tf workspaces /remove:*

Deleting the workspace and cache was not sufficient for me. I had to also restart the "Visual Studio Team Foundation Build Service Host" service.

TDN's solution worked for me when I was having the same issue. The Build server created workspaces under my account. Checking this box allowed me to see and delete them.

If you don't have permissions on the server to delete other people's workspaces, you can just change the name of the build definition. TFS will create a new workspace and map it to "C:\Build\ProductReleases\new build name here\Sources".

If applicable, you can also clone the build definition and change its name. This workded for me.

I had a similar issue and to remove the workspace that was causing me a problem, I logged into another machine with TFS client installed and performed the following:

• On the File menu, point to Source Control, Advanced, and then click Workspaces....
• In the Manage Workspaces dialog box, tick the Show remote packages checkbox.
• Under the Name column, select the workspace that you want to remove, and then click Remove.
• In the Confirmation dialog box, click OK.

I got same issue in Visual Studio 2017 and TFS 2017. DefaultCollection must be mapped first to you local path. Somehow this step was skipped and I got only MyFirstProject mapped.

All you need to do is:
- 1. Go to your TFS web page and remove the project from the server.

- 2. Remove the project from your local "Worksapces"

- 3. Go to "Manage Connections" which will refresh your Home page in TeamExplorer.

- 4. You will get Configuration page which will allow you to setup root path to your DefaultCollection.

- 5. You should get message that it been done successfully. Now you can create your project.

It's important to map root of your collection to your workspace first and then map a new project.

Just delete the contents of the following folder(s):

C:\Users\UserName\AppData\Local\Microsoft\Team Foundation\3.0\Cache

Where UserName is actual or current user, and 3.0 is the version number.

My issue was related to using multiple accounts. This is how I was able to switch accounts.

Open Team Explorer

From the big drop down menu near the top of the pane...

Navigate to: Projects and my Teams>Manage Connections

Navigate to: Manage Connections>Connect to Team Project

Use the "Switch User" link to switch accounts.

Now the workspace names will match the chosen account.

While trying to 'Get latest version' of a project which I had previously mapped to a local directory and then deleted, I saw this same error message. First I tried the SideKick tool and then the Visual Studio 2010 command prompt, both of which told me I had no workspaces mapped.

Next I searched for 'VersionControl.config' within c:/users/myuser/appdata, and deleted the 4 references it found. I re-opened Visual Studio and I was able to re-map the project, no more error!

Simply delete the workspace:

workspace /delete "the-workspace-name"

I couldn't get any other solution to work.

I had a new account created and the old account no longer had permissions (both on same machine).

I tried: 1) Deleting the workspace (couldn't see in VS with or without remote workspaces checked) 2) Deleting from the command line 3) New owner command 4) Deleting the cache

So I simply opened VS as admin and mapped to a different folder.

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}\AppData\Local\Microsoft\Team Foundation\3.0\Cache or C:\Users{UserName}\AppData\Local\Microsoft\Team Foundation\4.0\Cache

I was getting an exception telling me that the file was already mapped in another workspace: "The path {File Path} is already mapped in workspace {Workspace Name}."

This workspace was deleted beofre. With the help of friend of mine I found out that TFS save workspace info under the user local settings dir. We found a file named:

VersionControl.config under {User Documents and Settings dir}\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache. This file contains all the local mapping of TFS. Probably when you use the Map method and don't use: public void DeleteMapping(WorkingFolder mapping); before deleting the workspace the mapping information is not removed from this file which is used by TFS to check if you've alreay mapped a specific path.

To resolve this problem delete all the keys from the config file. Don't delete the file because you'll get it again from the server cache.

We had the same problem but deleting the workspace's from the TFS server did not work. (I should mention that I grabbed my colleagues VM that was already set up with his credentials.)

For me this worked: http://blogs.msdn.com/b/buckh/archive/2006/09/12/path-is-already-mapped-in-workspace.aspx

I just went into the : ...\Local Settings\Application Data\ made a search for VersionControl.config, opened up the folder that contained this file and deleted all of it's contents.

Previous to that I tried manually editing the file but it continued with the same error message.

I hope this helps.

While trying to 'Get latest version' of a project which I had previously mapped to a local directory and then deleted, I saw this same error message. First I tried the SideKick tool and then the Visual Studio 2010 command prompt, both of which told me I had no workspaces mapped.

Next I searched for 'VersionControl.config' within c:/users/myuser/appdata, and deleted the 4 references it found. I re-opened Visual Studio and I was able to re-map the project, no more error!

Deleting the workspace and cache was not sufficient for me. I had to also restart the "Visual Studio Team Foundation Build Service Host" service.

I had a similar problem with Visual Studio 2010 complaining about an already-mapped-workspace, but instead of deleting the entire workspace, I used the following from the Visual Studio Command Prompt: "tf workspace PROBLEM_WORKSPACE_NAME". This brought up an "Edit Workspace" dialog. From there I was able to remove the path in question from the "Working Folders" list, which got rid of the error.

I had this issue with this with Azure DevOps automated builds in an on-prem TFS build agent. Removing the workspace using TFS Sidekicks did not work. And tf.exe could not even find the workspace to delete it.

This solution should work for TFS 2017, TFS 2018, Azure DevOps, and possibly other versions:

1. Take note of the workspace GUID in the error message.
2. On the machine where the build is taking place, navigate to: %USERPROFILE%\AppData\Local\Microsoft\Team Foundation\ (where %USERPROFILE% belongs to the user that triggered the build).
3. Search for and remove all instances of the workspace GUID under that directory. There will likely be a folder in a 'cache' directory, as well as entries in 'LocationServerMap.xml' and 'LocalItemExclusions.config'. Remove them all.

That worked in my circumstance.

I was getting an exception telling me that the file was already mapped in another workspace: "The path {File Path} is already mapped in workspace {Workspace Name}."

This workspace was deleted beofre. With the help of friend of mine I found out that TFS save workspace info under the user local settings dir. We found a file named:

VersionControl.config under {User Documents and Settings dir}\Local Settings\Application Data\Microsoft\Team Foundation\1.0\Cache. This file contains all the local mapping of TFS. Probably when you use the Map method and don't use: public void DeleteMapping(WorkingFolder mapping); before deleting the workspace the mapping information is not removed from this file which is used by TFS to check if you've alreay mapped a specific path.

To resolve this problem delete all the keys from the config file. Don't delete the file because you'll get it again from the server cache.

Here is what I did (well what I do):

Using TFS Sidekicks clear out the user and server filters so they are blank. This will let you get all workspaces.

Check the build error for the workspace name. In the OPs case it is BuildServer_23. It is different in my environment but basically just match up the error name with the one in the tfs sidekick list.

Click the red x to delete the workspace.

Viola!