TFS API: GetLocalWorkspaceInfo always returns null

Question

On one of my machines, I get a return value of null from any GetLocalWorkspaceInfo call. I have isolated to problem to where it even fails for this simple program:

namespace WorkstationTest
{
    using Microsoft.TeamFoundation.VersionControl.Client;

    class Program
    {
        static void Main()
        {
            string workspaceLocalPath = @"C:\Dev";
            var info = Workstation.Current
                          .GetLocalWorkspaceInfo(workspaceLocalPath);

            // info is always null here
        }
    }
}

What I have already checked:

• The exact same code works on my other machine the way it should.

• I have verified that I have a workspace at C:\Dev

  

• I have created a new workspace and in a different directory and changed the workspaceLocalPath variable in the code to match.

• I have consulted the documentation which states that the return value will be null if the path is not in a workspace. From the above image, the path should be in a workspace.

Yet, everything seems to suggest this should work. Is there anything I could be missing?

Answer 1

After migrating from TFS2013 to TFS2017 in the company I work for I had the same problem with Workstation.Current.GetLocalWorkspaceInfo.

What worked for me is a call to Workstation.EnsureUpdateWorkspaceInfoCache:

TfsTeamProjectCollection tpc = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri("<your-tfs-uri-here>"));
VersionControlServer tfServer = tpc.GetService<VersionControlServer>();
Workstation.Current.EnsureUpdateWorkspaceInfoCache(tfServer, tfServer.AuthorizedUser);

I added the above code lines to the constructor of my TFS proxy class that uses GetLocalWorkspaceInfo.

Answer 2

When executing tf workspaces (on my computer) in the Visual Studio 2010 command prompt it says No workspace matching * found on this computer, but when executing the same command in Visual Studio 2012 it returns back all my expected workspaces.

The issue can be resolved by doing any of the following:

• Reference the version of the Microsoft.TeamFoundation.VersionControl.Client dll that was connected with Visual Studio 2012 instead of the dll connected with Visual Studio 2010.

• Open Visual Studio 2010 and connect it to TFS to where it will create the workspaces for Visual Studio 2010

Answer 3

I know this is an old post, but just like to share the workaround that we have, by using VersionControlServer.QueryWorkspaces to query all the workspaces for the user on his/her machine.

private static Workspace FindWorkspaceByPath(TfsTeamProjectCollection tfs, string workspacePath)
{ 
    VersionControlServer versionControl = tfs.GetService<VersionControlServer>();

    WorkspaceInfo workspaceInfo = Workstation.Current.GetLocalWorkspaceInfo(workspacePath);

    if (workspaceInfo != null)
    {
        return versionControl.GetWorkspace(workspaceInfo);
    }

    // No Workspace found using method 1, try to query all workspaces the user has on this machine.
    Workspace[] workspaces = versionControl.QueryWorkspaces(null, Environment.UserName, Environment.MachineName);
    foreach (Workspace w in workspaces)
    {
        foreach (WorkingFolder f in w.Folders)
        {
            if (f.LocalItem.Equals(workspacePath))
            {
                return w;
            }
        }
    }

    throw new Exception(String.Format("TFS Workspace cannot be determined for {0}.", workspacePath));
}

Answer 4

In my case, this issue occurred because of VersionControl.config file put under TFS cache folder (C:\Users\DeepakR\AppData\Local\Microsoft\Team Foundation\5.0\Cache\Volatile\0cb76a25-2556-4bd6-adaa-5e755ac07355_http) goes for a toss i.e. the configured workspace information weren't available as expected.

So, it basically needs a refresh of VersionControl.config file. Auto Refresh happens when Visual Studio gets loaded again i.e. it pulls the configured workspace information from Server and updates the config file or even if we execute tf command utility (tf.exe workspaces /collection:TFSURL)

Microsoft.TeamFoundation.VersionControl.Client's (v12.0.0.0) Workstation class has a function EnsureUpdateWorkspaceInfoCache which will do the same trick

VersionControlServer vcs = (VersionControlServer)tpc.GetService(typeof(VersionControlServer));
Workstation.Current.EnsureUpdateWorkspaceInfoCache(vcs, Environment.UserName);

https://msdn.microsoft.com/en-us/library/microsoft.teamfoundation.versioncontrol.client.workstation.ensureupdateworkspaceinfocache(v=vs.120).aspx

Hope the suggestion helps to resolve the issue.

Answer 5

I had this issue recently (today) using Visual Studio 2017, plus several other versions installed and a number of local workspaces.

I ended up updating the 'Team Foundation Server Client' NuGet package to the latest version (15.x) through the 'Manage NuGet Packages' menu and that fixed it.

I did also remove the existing project references first but that part might depend on what you need.

Answer 6

Simply run with the tricks.

Nothing is going to work properly without a proper DLL reference. The below had fixed the same issue i had for 5 days as it was screwing my time up.

Place the below DLL's in the bin folder of your project and give a reference to the whole solution for all the DLL's. If any error comes up like 'Reference could not be given' ignore it and skip that DLL from giving reference instead just place also the error creating DLL in bin folder which the project will automatically take during build

DLL's:

Microsoft.TeamFoundation.Client.dll                                  
Microsoft.TeamFoundation.Common.dll                                   
Microsoft.TeamFoundation.Core.WebApi.dll                              
Microsoft.TeamFoundation.TestManagement.Client.dll                    
Microsoft.TeamFoundation.TestManagement.Common.dll                    
Microsoft.TeamFoundation.Work.WebApi.dll                              
Microsoft.TeamFoundation.WorkItemTracking.Client.DataStoreLoader.dll  
Microsoft.TeamFoundation.WorkItemTracking.Client.dll                  
Microsoft.TeamFoundation.WorkItemTracking.Common.dll                  
Microsoft.TeamFoundation.WorkItemTracking.Controls.dll                
Microsoft.TeamFoundation.WorkItemTracking.Proxy.dll                   
Microsoft.TeamFoundation.WorkItemTracking.WebApi.dll                  
Microsoft.VisualStudio.Services.Client.Interactive.dll                
Microsoft.VisualStudio.Services.Common.dll                            
Microsoft.VisualStudio.Services.WebApi.dll                            
Microsoft.WITDataStore32.dll                                          
Microsoft.WITDataStore64.dll                                          

The above dll's can be found in the below path if the System is installed with MTM or TFS

Path: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer

Answer 7

In my C:\Users\<username>\AppData\Local\Microsoft\Team Foundation folder I had 2 folders:

• 7.0

• 8.0

Within the 8.0 folder was the following folder:

\Cache\Volatile\c1dbda02-c575-4dd2-b221-e83f7cb63665_http

But within the 7.0 folder the \Cache\Volatile folder was empty

So all I did was copy across the c1dbda02-c575-4dd2-b221-e83f7cb63665_http folder into 7.0\Cache\Volatile\

After this GetLocalWorkspaceInfo call returned the workspace info successfully

Answer 8

This is how to find workspace when you have server path:

  Workspace[] workspaces = _versionControl.QueryWorkspaces(null, Environment.UserName, Environment.MachineName);
  return workspaces.FirstOrDefault(w => !string.IsNullOrEmpty(w.TryGetLocalItemForServerItem(ConstDefaultFlowsTfsPath)));

Where ConstDefaultFlowsTfsPath is server path with "$" for instance : "$/MyCompany/Services/DiagnosticsFlows"

You could also replace the last line to:

return workspaces.FirstOrDefault(w => !string.IsNullOrEmpty(w.GetServerItemForLocalItem(myLocalPath)));

and that should work for you too.