TFS API Workspace.Get & Writing to the file system

TFS API Workspace.Get & Writing to the file system

• SabineA

  Good catch. Get will silently fail if your credentials don't have Read permission.
  
  

• Xancholy

  Hi Richard,

  How do I know if the credentials don't have read permission

  10x

  Ofir

  
  

• pradeepyr

  I think I figured out the root cause of this.

  I changed my code to instantiate the TeamFoundationServer class with an instance of the INetworkCredential interface.

  It seems to have resolved the issue and all Get methods are working as documented.

  Thanks for everyone's help. I have posted my code change below.

  NetworkCredential c = new NetworkCredential(ConfigurationManager.AppSettings["configAPIUser"],

  ConfigurationManager.AppSettings["configAPIPassword"],

  ConfigurationManager.AppSettings["configAPIDomain"]);

  using (TeamFoundationServer tfs = new TeamFoundationServer(ConfigurationManager.AppSettings["TeamFoundationUrl"], c))

  {

  }

  
  

• donkaiser

  thanks for the quick responses

  I am passing in the GetOptions.GetAll | GetOptions.Overwrite to all of my workspace.Get dispatches.

  There seems to be a couple of weird things happening:

  1.) The recursive request for a server folder path only builds the folder structure for me. It doesn't build the files.

  2.) The individual file requests for the files have the GetOptions specified above and it doesn't put them on the file system. At least according to windows explorer/ System.IO.File.Exists. But when I go to do a save as on a notepad as the file I just did the get operation it then shows the file as being there. But it still doesn't recognize the file in windows explorer.

  I also added event handlers for the getting and operationcompleted events and they were fired and had the appropriate file data. Also, the GetStatus class returns the correct number of operations and doesn't have any errors.

  This is why I believe that there might be a buffer cache somewhere that needs to be flushed.

  Here is some sample code:

  using (TeamFoundationServer tfs = new TeamFoundationServer(ConfigurationManager.AppSettings["TeamFoundationUrl"]))

  {

  //Get the version control server from the tfs server

  VersionControlServer versionControl = (VersionControlServer)tfs.GetService(typeof(VersionControlServer));

  Workspace ptrworkSpace = versionControl.GetWorkspace(ConfigurationManager.AppSettings["TeamFoundationWorkspace"], versionControl.AuthenticatedUser);

  //The Get on the Folder path; I have validated that it is a valid mapped path. This creates a recursive folder structure on the client that is correct

  GetStatus s1 = ptrworkSpace.Get(new GetRequest(new ItemSpec(tfsRootDirPath, RecursionType.Full), VersionSpec.Latest), GetOptions.GetAll | GetOptions.Overwrite);

  //The Get on a file in the above metioned folder path. After this dispatch the GetStatus instance will display no errors and correct operations but there is no file on the filesystem

  GetStatus s2 = ptrworkSpace.Get(new GetRequest(new ItemSpec(tfsRootWebConfig, RecursionType.None), VersionSpec.Latest), GetOptions.GetAll | GetOptions.Overwrite);

  //A get on a file that is a couple of folders deep from the original get. This behavior is the same as the above file get

  GetStatus s3 = ptrworkSpace.Get(new GetRequest(new ItemSpec(tfsEnvironmentWebConfig, RecursionType.None), VersionSpec.Latest), GetOptions.GetAll | GetOptions.Overwrite);

  }

  
  

• StumblingInTheDark

  Get() will only retrieve files once, unless a new version exists on the server. So if you do a recursive Get, a subsequent Get on a child file won't do anything. This is just like the "all files up to date" message seen in tf get and Source Control Explorer. So long as you don't modify any files on disk without going thru TFS, that should suffice. If you need to force a Get to happen even when TFS thinks you have the latest version, use GetOptions.GetAll.
  
  If you register a handler for the VersionControlServer.Getting event then you can see exactly what's happening.
  
  

• kennm

  Is there any possibility that your issue is due to the fact that TFS only downloads new files on Get if it thinks you are out-of-date For instance, if in your testing you were to perform the Get on the files via server-path and then deleted the file(s) locally before trying the Get on the same file(s) using local path, you would not download anything on the second attempt. This is because TFS believes you still have the most current version of on disk. It doesn't realize you've deleted the files.

  If you pass the "force" option to Get it will ignore this optimization and will always download the file(s) specified.

  --Ben Ryan

  
  
  
• TFS API Workspace.Get & Writing to the file system