tfsbuildworkflow-activity

TFS 2013 convert server path to local path


How would I convert server path like "$/Test/BuildResources" to ex: "D:\test\etc.."

I'm running TFS 2013. Would I use "GetWorkspace" item?

When I try to use "GetWorkspace" and specify "$/Test" in the Name field I get an error message. Not sure if this is the way to do it. thanks

EDIT:

This is what I tried. This is my setup:

I'm trying to convert "$/IW_Xavier/Deployment" to local path enter image description here enter image description here

I also added GetWorkspace and set it up like this: enter image description here enter image description here

But it doesn't convert it: enter image description here

I get an error message. I also tried using "GetLocalPath"-not sure if this does what I want but it also doesn't work.

EDIT 2:

This is what I ended up doing: 1. Added the path in "Source Settings" enter image description here

  1. Under "Process" tab I store a server path in a variable "DeploymentScript" enter image description here
  2. Added "GetLocalPath" from the toolbox and used a variable for Output enter image description here

This worked for me. I get a local path (C:\blah\blah...) for "#\IT_dfj" etc Thanks a lot


Solution

  • You don't have to convert it. If you already know the server path,you can directly get the workspace by using this method Workspace.GetLocalItemForServerItem

    Please refer the answer from Edward Thomson which including very detailed explanation about using TFS API to query server and local path.

    If you have a given local path (in this case, your SourcesDirectory) you can use that to read the workspace cache and get the information you need for the server connection that the build server has created:

    // Get the workspace information for the build server's workspace
     var workspaceInfo = Workstation.Current.GetLocalWorkspaceInfo(sourcesDirectory);
    
    // Get the TFS Team Project Collection information from Edward Thomson  the workspace cache
    // information then load the TFS workspace itself.
     var server = new TfsTeamProjectCollection(workspaceInfo.serverUri);
     var workspace = workspaceInfo.GetWorkspace(server);
    

    Once you have a workspace, you can query it for the path mappings. It will do the necessary translation from server to local path based on your workspace mappings. For example:

    workspace.GetServerItemForLocalItem("D:\My\Local\Path");
    

    and

    workspace.GetLocalItemForServerItem("$/My/Server/Path");
    

    This mechanism will only work, however, if your build definition actually sets up the workspace to include these files. If you need some directory $/Foo/Bar, you will need to make sure that it is included in the Source Settings details tab of the Build Definition.

    Source: How do I resolve the root and relative paths of TFS folders on the server?

    Moreover, if you have to convert both, you can also use an ConvertWorkspaceItem activity to achieve it.

    And in "GetWorkspace" activity for the Name field, you must specify a workspace name(such as "MyWorkspace" ) or a variable which get the workspace name.

    enter image description here


    Updated

    Sorry for the misunderstanding, finally I got what you're doing.

    First, The workspace only stand for this, so the get workspace and workspace name will return :FABRIKAM-1

    enter image description here

    And this is source control folder and local folder, this is a mapping Relationship. Of course this is in your dev machine.

    enter image description here

    However, you want to convert the server path to local path , want to get the path of MSTest file, but this is running on your build agent. So you don't need to looking for it in your dev machine, you just need to looking for the path on build agent.

    What you are looking for is still the TF_BUILD_BUILDDIRECTORY (The build agent working directory). Then add the Relative path such as xx\..\... Just as this case said, TFS How to GetEnvironmentVariable value . You can't get it directly through the custom process.

    So .......the ultimate solution. Suggest you to run a script in your build process or use the 2015 new build (vNext build), then everything should be OK. :)