2013-04-11 1 views
24

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

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 в коде, чтобы соответствовать.

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

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

+1

Что вы получаете, если вы вызываете 'WorkspaceInfo [] все = Workstation.Current.GetAllLocalWorkspaceInfo()'? –

+0

@ConradClark Я только что нашел проблему, я нахожусь в середине написания ответа. Эта линия дала бы мне точный толчок, который мне понадобился бы, если бы я не понял его с чем-то похожим. «GetAllLocalWorkspaceInfo» вернул бы, что не было рабочих пространств. Спасибо за помощь! –

+0

Помогает ли человек, который уменьшил осторожность, чтобы объяснить, что не так с вопросом и как его можно улучшить? –

ответ

5

Я знаю, что это старое сообщение, но просто как разделить обходное решение, которое у нас есть, используя 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)); 
} 
+0

Спасибо, что поделились! –

+0

Для меня это не работает. f.LocalItem никогда не соответствует рабочему пространству Путь, потому что мой рабочий путь - это папка, которая существует глубоко внутри системы папок. –

+0

Еще одна вещь, о которой нужно помнить, заключается в том, что 'Environment.UserName' не всегда является фактическим именем пользователя TFS. Поэтому вам может потребоваться изменить аргумент на 'QueryWorkspaces' в соответствии с именем пользователя TFS. – Nathan

14

При выполнении 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.

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

+0

Спасибо! Это сделало это для меня. Я использовал DLL-библиотеки v10, потому что наш сервер TFS2010, но поскольку я использую Visual Studio 2012 локально, мне нужно было использовать DLL-файлы v11. – ben

+1

@ben Я рад, что это помогло кому-то другому! Я немного боролся с формулировкой, но это может иметь смысл для того, кто переживает то же самое. Если вы видите способ улучшить то, что я сказал, что упростило бы понимание того, что вам в итоге пришлось сделать, чтобы исправить это, отредактируйте его. –

+1

@ben Кроме того, я собирался опубликовать следующий вопрос, так как некоторые из нашей команды все еще используют VS2010, а некоторые используют VS2012. Вопрос заключается в том, почему рабочие пространства должны управляться отдельно, и если есть способ управлять отключением этой ссылки dll на основе того, что они работают. Я никогда не обходился. Не могли бы вы подумать, что это тоже выгодно? –

7

В моем случае эта проблема произошла из-за VersionControl.config файла поставить под кэш TFS (C: \ Users \ DeepakR \ AppData \ Local \ Microsoft \ Foundation Team \ 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

Надежда предложение помогает решить эту проблему.

0

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

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

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

1

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

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

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

12

После миграции из 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.

+0

GetLocalWorkspaceInfo внезапно возвращал null после того, как YEARS правильно работал. Помещение этих трех строк кода выше вызова немедленно устранило проблему. –

+0

Это должен быть ответ. –

+0

Это решение, которое я искал, и стоит отметить, что этот код, вероятно, нужно выполнить только один раз и может быть удален после этого. – friznani

0

Просто запустите с помощью трюков.

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

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

библиотек:

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

 Смежные вопросы

  • Нет связанных вопросов^_^