Already mapped to a workspace error

Question

Hi, I'm ising TFS 2008

when I delete a build definition & create another build definition of the same name, the build fails for the following reason: 

The path C:\Documents and Settings\NetworkService\Local Settings\Temp\~\Sources is already mapped in workspace Myworkspace.

I've discovered this is because it doesn't delete the underlying workspace info. Apparently it is in a config file named VersionControl.Config. However I haven't been able to find this file anywhere on my EX machine or on my 2K3 server.

either the file is named differently or I'm barking up the wrong tree. I need to delete residual information of all the deleted Build definitions in order to create a build definition with a name used for a previous build definition.

Anybody out there know i) what this file is really called ii) where it is located & iii) what this rambling idiot (me) is talking about?

Thanks all the same

---

@nt

Answer 1

Hi,

If you create a build definition and run a build with it this creates a workspace associated with the account that executes the build. The workspace is created with the mappings defined in the build definition. Now if you delete the build definition the workspace might not get deleted. If you then create a new definition with the same workspace mappings and the same name you will get the this message ("... is already mapped ..."). To get rid of it you will have to delete this workspace. You can do this with tf.exe or if you open Visual Studio with the account that executes the build on the build agent.

Answer 2

you can also use http://www.attrice.info/cm/tfs/index.htm to assist with workspaces.

Answer 3

Hi ACKH,

Thanks for your time in responding however I don't believe this is the solution. Here's why:

I create a new Build definition. In workspace, I add the standard workspacew mappings I generally add, say:

Source control folder = $/MySolution; Local Folder = $(SourceDir);

This works fine every time I create a brand new build definition.

when I delete an existing build definition, say, TestBuild, I add the same worksapce info as I do above.
Source control folder = $/MySolution; Local Folder = $(SourceDir);
It builds fine.

I then delete this build definition & recreate another one by the same name: TestBuild.
however, this time it doesn't build fine, it errors with:

The path D:\BldRpt\SolutionName\TestBuild\Sources is already mapped in workspace TFS_19

Firstly, I don't have  a workspace named TFS_19.I didn't use a predefined workspace. I just mapped it so in the background it must have created this. I need to delete this TFS_19 workspace but I can't find it as its a machine generated one. (I guess)

Besides, the fact that I can create new build definition to my hearts content without ever having to delete a workspace until I create one that is named the same as a previously deleted one seems fishy to me. I don't think this is related to a workspace I created.

D oyou know how I can acess where these hidden workspaces are kept?

many thanks for all your help

I generally only use a few predefined workspaces, not one for each build definition. i have no trouble sharing these workspaces with differerent build definitions. it's only when I delete a build definition & try to recreate a new one sharing the same name that the issue occurs. A bing found this is not an uncommon issue & the resolution revolved around editing the contents of a certain VersionControl.config file  http://www.ryanmcdonnell.com/the-path-is-already-mapped-to-workspace/

however, I can't find this file on my XP pro Workstation.

---

@nt

Answer 4

By default a workspace name created by Team Foundation Build consists of the computer name followed by the id of the build definition. If you did not change this pattern "TFS_19" is a workspace for the machine "TFS" created by the build definition with id 19.

Such a workspace is created for the account that actually runs the build. You can check which account this is by checking which user account is used to run the "Visual Studio Team Foundation Build" service. This user account should be the owner of "TFS_19". Once you have the owner you can use

"%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe" workspaces /owner:<the owner you figured out>

to check if the workspace "TFS_19" is owned by the account that runs the Team Foundation Build service. You can then get rid of it by deleting that workspace using

"%ProgramFiles%\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe" workspace /delete TFS_19;<domain>\<the owner you figured out> /server:<servername>"


As far as I know the VersionControl.config comes from TFS 2005 / Team Foundation Build 2005. In that version you had an xml file that defined the workspace mappings. But your descriptions I assume you are using TFS 2008.


To fully get rid of the problem you have to inspect the "Working directory" of the build agent your build is running on. If you do not use variables (i.e. $(BuildDefinitionId)) in there the path that is used for the old build definition and the one that replaces it is the same which is why you end up with that problem.