Schema for the WorkspaceMapping.xml file

Buck Hodges

The WorkspaceMapping.xml file is one of the files generated when creating a new build type.  Those of you who’ve had to customize a build are probably familiar with the TfsBuild.proj file, which is the top-level file used to orchestrate the build.

The WorkspaceMapping.xml file is used by one of the custom tasks to create the TFS workspace that contains the files to be built.  In version 1 of Team Build, you must edit the WorkspaceMapping.xml file in order to change the mappings used by the workspace created for the build (in Orcas, you can do this in the GUI, and this file is no longer generated or used).

There’s no formal schema on MSDN.  Here are the rules.

  • The ServerItem should be a valid server path.
  • The server paths must all be in the same team project.
  • A server path can either be mapped or cloaked (for more information on mappings, see this MSDN topic on working folder mappings).
  • The local path for a mapped server item needs to be a legal local path, but it’s otherwise completely ignored.  This is an important difference between this workspace mapping template file and real source control mappings that you may be used to.
  • Do not specify local paths for cloaked mappings.
  • All cloaked paths must be children of mapped paths (cloaking is just a means of avoiding getting parts of an otherwise mapped tree).

Here’s an example of a mapped and cloaked path.

<?xml version=”1.0″ encoding=”utf-8″?>

<SerializedWorkspace xmlns:xsi=”” xmlns:xsd=””>


    <InternalMapping ServerItem=”$/TeamProject/Some/Path” LocalItem=”c:thispathisignored” Type=”Map” />

    <InternalMapping ServerItem=”$/TeamProject/Some/Path/Cloaked” Type=”Cloak” />



This post only applies to Team Foundation Server 2005.

tags: , ,


Leave a comment

Feedback usabilla icon