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?

Insphere

What do you get if you call WorkspaceInfo[] everything = Workstation.Current.GetAllLocalWorkspaceInfo()? – Birdie

@ConradClark I just found the problem, I am in the middle of writing up an answer. That line would have give me the exact nudge I would have needed if I wouldn't have figured it out with something similar. The GetAllLocalWorkspaceInfo would have returned that there were no workspaces. Thank you for your help! – Insphere

Does the person who downvoted care to explain what is wrong with the question and how it can be improved? – Insphere

see @Deepak Ramalingam's answer (https://mcmap.net/q/462064/-tfs-api-getlocalworkspaceinfo-always-returns-null) for a simple, code-only solution to try first. It was all I needed to get around this issue. – Carioca

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.

Latterll

GetLocalWorkspaceInfo was abruptly returning null after YEARS of working properly. Putting these three lines of code above the call fixed the issue immediately. – Teece

This should be the answer. – Agata

This is the solution I was seeking, and it's worth noting that this code probably only needs to execute once and may be removed thereafter. – Rebozo

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

Insphere

Thanks! This did it for me. I had used the v10 DLLs because our server is TFS2010, but because I'm using Visual Studio 2012 locally I needed to use the v11 DLLs. – Incursion

@Incursion I am glad to see this helped someone else! I struggled with the wording a little bit, but it might make sense to someone who is going through the same thing. If you see a way to improve what I said that would have made it easier to understand what you eventually had to do to fix it, please feel free to edit. – Insphere

@Incursion Also, I was going to post a follow up question, since some of our team is using VS2010 still and some are using VS2012. The question would be why the workspaces have to be separately managed, and if there is a way to manage switching out that dll reference based on what vs they are running. I never got around to it. Would you think this is something that would be beneficial as well? – Insphere

Its obviously been awhile, but could you add the changes required for tfs 2013 with visual studio 2012 and 2013? Also, could you expound what you mean by "connect it to TFS to where it will create the workspaces" for an existing workspace. – Ulterior

Thank you! In my case I can't reference the Microsoft.TeamFoundation.VersionControl.Client.dll for TFS/Visual Studio 2013 because the project consuming it is built with VS2010 and targets .net 3.5, Microsoft.TeamFoundation.VersionControl.Client.dll targets .net 4, so Visual Studio 2010 produces an error during a build. It works when I launch Visual Studio 2010 and connect to the TFS 2013 server and refresh the workspace, but unfortunately I have to do this manually every time and haven't found a more decent workaround (yet). In my case, running tf.exe workspaces prints the expected workspaces. – Catalonia

So does this basically mean, that we need to provide a different version of a "TFS-plugin" for our custom app for each version of visual studio? The installer of our app would need to find out what version of VS is installed? – Hoyle

@Hoyle I cannot confirm what you are saying, but I think that makes sense since the TFS client is only working for the connected version of the library. – Insphere

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));
}

Yachtsman

For me it isn't working. f.LocalItem never equals to workspace Path because my working path is folder that exists deep inside of folder system. – Fixate

One other thing to keep in mind is that Environment.UserName is not always the actual TFS username. So you may need to change the argument to QueryWorkspaces to match the TFS username. – Proust

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.

Slaughterhouse

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.

Overdue

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

Insurmountable

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

Matheson

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.

Fixate