locked
TFS build fails due to workspace conflicts (TFS 2012) RRS feed

  • Question

  • I'm getting a common build error when trying to build different build definitions:

    Exception Message: Unable to create the workspace '35_6_xxxbld01' due to a mapping conflict. You may need to manually delete an old workspace. You can get a list of workspaces on a computer with the command 'tf workspaces /computer:%COMPUTERNAME%'. Details: The path D:\xxxBuild\Sources\1205 is already mapped in workspace 38_6_xxxbld01. (type MappingConflictException)Exception Stack Trace:    at Microsoft.TeamFoundation.Build.Workflow.Activities.TfCreateWorkspace.Execute(CodeActivityContext context)   at System.Activities.CodeActivity`1.InternalExecute(ActivityInstance instance, ActivityExecutor executor, BookmarkManager bookmarkManager)   at System.Activities.Runtime.ActivityExecutor.ExecuteActivityWorkItem.ExecuteBody(ActivityExecutor executor, BookmarkManager bookmarkManager, Location resultLocation)Inner Exception Details:Exception Message: The path D:\xxxBuild\Sources\1205 is already mapped in workspace 38_6_xxxbld01. (type MappingConflictException)Exception Stack Trace:    at Microsoft.TeamFoundation.VersionControl.Client.InternalCache.CheckForMappingConflicts(WorkspaceInfo workspaceToCheck, WorkspaceInfo workspaceToIgnore)   at Microsoft.TeamFoundation.VersionControl.Client.Client.CreateWorkspace(CreateWorkspaceParameters cwp)   at Microsoft.TeamFoundation.Build.Client.BuildClientUtil.CreateWorkspace(VersionControlServer versionControl, String name, IEnumerable`1 folders, String comment, IEnumerable`1 wsSecurity)   at Microsoft.TeamFoundation.Build.Workflow.Activities.TfCreateWorkspace.Execute(CodeActivityContext context)

    I can delete the offending workspace 38_6_xxxbld01 and this particular build definition will start working.  But then a different build definition will stop working for the same error on a different workspace.  I did not need to do anything special with workspace mappings when running TFS 2010.

    At one point, we had the 2010 build agent running on this machine (the one where the 2012 build agent is now running), but I *believe* that no 2010 service is running anymore -- at least I can't see one.

    I appreciate any insight.



    Erik Dahl

    Wednesday, July 18, 2012 11:24 PM

Answers

  • Hi Erik,

    you shouldn't manipulate how the build creates the sources directory. In your case it seems as if the default configuration of the build agents is wrong. The build working directory for the agent should be e.g.:

    d:\Builds\$(BuildAgentId)\$(BuildDefinitionPath)

    or in case you need shorter paths:

    d:\Builds\$(BuildAgentId)\$(BuildDefinitionId)

    If this is the case, each build definition will have it's own mapping folder since it will have another id. The $(SourceDir) from the build definition's workspace then is mapped to d:\Builds\$(BuildAgentId)\$(BuildDefinitionId)\Sources which is unique.

    BTW: the workspace name consists of $(BuildDefinitionId)_$(BuildAgentId)_$(BuildAgentName) e.g. 38_6_Build01.

    Hope this helps.

    Sven

    AIT TeamSystemPro Team


    AIT AG

    • Proposed as answer by Sven Hubert (AIT) Tuesday, August 21, 2012 12:49 PM
    • Marked as answer by Erik Dahl Wednesday, August 22, 2012 12:47 PM
    Tuesday, August 21, 2012 12:49 PM
  • I was able to fix the problem by modifying the build workflow template.  I believe what was happening was that different build definitions were created, and by default they all seem to get pointed to a "Sources" directory.  I *may* have been able to do something with the build definition by differently defining the workspace, but my solution (to eliminate the need to make the same change in each build definition) was as follows:

    Open the build template xaml file (I copied the default one to a custom one).

    Find the Initialize Sources Directory task in the workflow.

    Withing the Properties for that task, change the Value to be the following: String.Format("{0}\Sources\{1}", BuildDirectory, BuildDetail.BuildDefinition.Id)

    After then using the tf workspace command to remove the existing workspaces, everything is now working! 


    Erik Dahl

    • Marked as answer by Erik Dahl Thursday, July 19, 2012 2:57 PM
    Thursday, July 19, 2012 2:57 PM

All replies

  • Hi Erik,

    Would you please try to re-create workspace that let workspace do not conflict just let currrently using one exists, or you can use tf workspaces /? command line list all workspace and delete all conflict ones, then try to edit build difinition with right workspace.

    More information, you can refer to:

    Create and Work With Workspaces

    Workspaces Command

    Regards,


    Lily Wu [MSFT]
    MSDN Community Support | Feedback to us

    Thursday, July 19, 2012 7:06 AM
    Moderator
  • I was able to fix the problem by modifying the build workflow template.  I believe what was happening was that different build definitions were created, and by default they all seem to get pointed to a "Sources" directory.  I *may* have been able to do something with the build definition by differently defining the workspace, but my solution (to eliminate the need to make the same change in each build definition) was as follows:

    Open the build template xaml file (I copied the default one to a custom one).

    Find the Initialize Sources Directory task in the workflow.

    Withing the Properties for that task, change the Value to be the following: String.Format("{0}\Sources\{1}", BuildDirectory, BuildDetail.BuildDefinition.Id)

    After then using the tf workspace command to remove the existing workspaces, everything is now working! 


    Erik Dahl

    • Marked as answer by Erik Dahl Thursday, July 19, 2012 2:57 PM
    Thursday, July 19, 2012 2:57 PM
  • I had this issue too.

    I deleted the build controller and agent on the TFS server and recreated them and that solved my issue.

    I also deleted my workspace, but probably didn't need to.

    • Proposed as answer by Sven Hubert (AIT) Tuesday, August 21, 2012 12:45 PM
    • Unproposed as answer by Sven Hubert (AIT) Tuesday, August 21, 2012 12:45 PM
    • Proposed as answer by Dan Trocchio Tuesday, December 18, 2012 5:11 PM
    • Unproposed as answer by Dan Trocchio Tuesday, December 18, 2012 5:11 PM
    Friday, August 3, 2012 12:35 AM
  • Hi Erik,

    you shouldn't manipulate how the build creates the sources directory. In your case it seems as if the default configuration of the build agents is wrong. The build working directory for the agent should be e.g.:

    d:\Builds\$(BuildAgentId)\$(BuildDefinitionPath)

    or in case you need shorter paths:

    d:\Builds\$(BuildAgentId)\$(BuildDefinitionId)

    If this is the case, each build definition will have it's own mapping folder since it will have another id. The $(SourceDir) from the build definition's workspace then is mapped to d:\Builds\$(BuildAgentId)\$(BuildDefinitionId)\Sources which is unique.

    BTW: the workspace name consists of $(BuildDefinitionId)_$(BuildAgentId)_$(BuildAgentName) e.g. 38_6_Build01.

    Hope this helps.

    Sven

    AIT TeamSystemPro Team


    AIT AG

    • Proposed as answer by Sven Hubert (AIT) Tuesday, August 21, 2012 12:49 PM
    • Marked as answer by Erik Dahl Wednesday, August 22, 2012 12:47 PM
    Tuesday, August 21, 2012 12:49 PM
  • This fixed it for me, thanks.
    Tuesday, December 18, 2012 5:11 PM