API TFS: GetLocalWorkspaceInfo всегда возвращает null

На одной из моих машин я получаю возвращаемое значение null из любого вызова GetLocalWorkspaceInfo. Я выделил проблему, где она даже не работает для этой простой программы:

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

Что я уже проверил:

  • Точный же код работает на моей другой машине так, как должен.

  • Я проверил, что у меня есть рабочее пространство в C:\Dev

    Workspace Screenshot

  • Я создал новое рабочее пространство и в другом каталоге и изменил переменную workspaceLocalPath в соответствующем коде.

  • Я проконсультировал документацию, в которой указано, что возвращаемое значение будет null if the path is not in a workspace. Из приведенного выше изображения путь должен находиться в рабочей области.

Однако все кажется, что это должно сработать. Есть ли что-нибудь, что я могу потерять?

Ответы

Ответ 1

Я знаю, что это старый пост, но просто как разделить обходное решение, которое у нас есть, используя VersionControlServer.QueryWorkspaces для запроса всех рабочих областей для пользователя на его машине.

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

Ответ 2

После перехода с TFS2013 на TFS2017 в компании, в которой я работаю, у меня возникла та же проблема с Workstation.Current.GetLocalWorkspaceInfo.

Для меня сработал звонок в Workstation.EnsureUpdateWorkspaceInfoCache:

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

Я добавил приведенные выше строки кода в конструктор моего прокси-класса TFS, который использует GetLocalWorkspaceInfo.

Ответ 3

При выполнении tf workspaces (на моем компьютере) в командной строке Visual Studio 2010 он говорит No workspace matching * found on this computer, но при выполнении той же команды в Visual Studio 2012 он возвращает все мои ожидаемые рабочие области.

Проблема может быть решена путем выполнения любого из следующих действий:

  • Ссылка на версию dll Microsoft.TeamFoundation.VersionControl.Client, которая была связана с Visual Studio 2012 вместо DLL, связанной с Visual Studio 2010.

  • Откройте Visual Studio 2010 и подключите его к TFS, где он будет создавать рабочие пространства для Visual Studio 2010

Ответ 4

В моем случае эта проблема возникла из-за файла VersionControl.config, помещенного под кешем TFS (C:\Users\DeepakR\AppData\Local\Microsoft\Team Foundation\5.0\Cache\Volatile\0cb76a25-2556-4bd6-adaa -5e755ac07355_http) идет для тотализатора, т.е. Сконфигурированная информация о рабочей области недоступна, как ожидалось.

Итак, он в основном нуждается в обновлении файла VersionControl.config. Auto Refersh происходит, когда Visual Studio снова загружается, то есть вытягивает настроенную информацию о рабочем пространстве с сервера и обновляет файл конфигурации или даже выполняет служебную утилиту tf (tf.exe workspaces/collection: TFSURL)

Класс рабочей станции Microsoft.TeamFoundation.VersionControl.Client(v12.0.0.0) имеет функцию EnsureUpdateWorkspaceInfoCache, которая будет делать тот же трюк

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

Надеемся, что предложение поможет решить проблему.

Ответ 5

У меня была эта проблема недавно (сегодня) с использованием Visual Studio 2017, а также нескольких других версий и нескольких локальных рабочих пространств.

Я закончил обновление пакета NuGet "Team Foundation Server Client" до последней версии (15.x) через меню "Управление пакетами NuGet" и исправил его.

Я также удалил существующие ссылки на проекты, но эта часть может зависеть от того, что вам нужно.

Ответ 6

Вот как найти рабочее пространство, когда у вас есть путь к серверу:

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

Где ConstDefaultFlowsTfsPath - это путь к серверу с "$", например: "$/MyCompany/Services/DiagnosticsFlows"

Вы также можете заменить последнюю строку на:

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

и это тоже должно работать для вас.

Ответ 7

Просто бегите с хитростями.

Ничто не будет работать должным образом без надлежащей ссылки на DLL. Приведенное ниже исправило ту же проблему, что и у меня, в течение 5 дней, так как это искажало мое время.

Поместите приведенную ниже DLL в папку bin вашего проекта и дайте ссылку на все решение для всех DLL. Если возникает какая-либо ошибка, такая как "Ссылка не может быть предоставлена", игнорируйте ее и пропустите эту DLL от предоставления ссылки, вместо этого просто поместите также DLL создания ошибки в папку bin, которую проект автоматически получит во время сборки

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

Указанные выше dll можно найти по указанному ниже пути, если Система установлена с MTM или TFS

Путь: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer

Ответ 8

В моей папке C:\Users\<username>\AppData\Local\Microsoft\Team Foundation было 2 папки:

  • 7.0

  • 8.0

В папке 8.0 была следующая папка:

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

Но внутри папки 7.0 папка \Cache\Volatile была пуста

Поэтому все, что я сделал, это скопировал из папки c1dbda02-c575-4dd2-b221-e83f7cb63665_http в 7.0\Cache\Volatile\

После этого GetLocalWorkspaceInfo вызов вернул информацию о рабочей области успешно