tfsteamprojectcollection teamfoundationserver microsoft extendedclient c# tfs-sdk

c# - teamfoundationserver - API de TFS: GetLocalWorkspaceInfo siempre devuelve nulo



microsoft teamfoundationserver extendedclient (7)

Al ejecutar las tf workspaces (en mi computadora) en el símbolo del sistema de Visual Studio 2010, dice No workspace matching * found on this computer , pero al ejecutar el mismo comando en Visual Studio 2012, devuelve todas mis áreas de trabajo esperadas.

El problema se puede resolver haciendo lo siguiente:

  • Consulte la versión de la dll Microsoft.TeamFoundation.VersionControl.Client que se conectó con Visual Studio 2012 en lugar de la dll conectada con Visual Studio 2010.

  • Abra Visual Studio 2010 y conéctelo a TFS donde creará las áreas de trabajo para Visual Studio 2010

En una de mis máquinas, obtengo un valor de retorno nulo de cualquier llamada a GetLocalWorkspaceInfo . Me he aislado al problema donde incluso falla para este simple programa:

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

Lo que ya he comprobado:

  • El mismo código exacto funciona en mi otra máquina como debería.

  • He verificado que tengo un espacio de trabajo en C:/Dev

  • He creado un nuevo espacio de trabajo y en un directorio diferente y he cambiado la variable workspaceLocalPath en el código para que coincida.

  • He consultado la documentación que indica que el valor de retorno será nulo if the path is not in a workspace . Desde la imagen anterior, la ruta debe estar en un área de trabajo.

Sin embargo, todo parece sugerir que esto debería funcionar. ¿Hay algo que pueda faltar?

Después de migrar de TFS2013 a TFS2017 en la empresa donde trabajo, tuve el mismo problema con Workstation.Current.GetLocalWorkspaceInfo.

Lo que funcionó para mí es una llamada a Workstation.EnsureUpdateWorkspaceInfoCache :

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

Agregué las líneas de código anteriores al constructor de mi clase de proxy TFS que usa GetLocalWorkspaceInfo.

En mi caso, este problema se produjo debido al archivo VersionControl.config colocado bajo el caché TFS (C: / Users / DeepakR / AppData / Local / Microsoft / Team Foundation / 5.0 / Cache / Volatile / 0cb76a25-2556-4bd6-adaa-5e755ac07355_http) la carpeta va para un lanzamiento, es decir, la información del espacio de trabajo configurado no estaba disponible como se esperaba.

Por lo tanto, básicamente necesita una actualización del archivo VersionControl.config. Auto Refersh sucede cuando Visual Studio se carga de nuevo, es decir, extrae la información del área de trabajo configurada del Servidor y actualiza el archivo de configuración o incluso si ejecutamos la utilidad de comando tf (espacios de trabajo tf.exe / colección: TFSURL)

La clase de la estación de trabajo de Microsoft.TeamFoundation.VersionControl.Client (v12.0.0.0) tiene una función, AsegureActualizar , Espacio de Información , Cache que hará el mismo truco

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

Workstation.EnsureUpdateWorkspaceInfoCache

Espero que la sugerencia ayude a resolver el problema.

Esta es la forma de encontrar el espacio de trabajo cuando tiene una ruta de servidor:

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

Donde ConstDefaultFlowsTfsPath es la ruta del servidor con "$" por ejemplo: "$/MyCompany/Services/DiagnosticsFlows"

También puede reemplazar la última línea para:

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

y eso debería funcionar para ti también.

Sé que esta es una publicación antigua, pero al igual que para compartir la solución que tenemos, mediante el uso de VersionControlServer.QueryWorkspaces para consultar todas las áreas de trabajo del usuario en su máquina.

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

Tuve este problema recientemente (hoy) con Visual Studio 2017, además de varias otras versiones instaladas y varias áreas de trabajo locales.

Terminé actualizando el paquete NuGet ''Team Foundation Server Client'' a la última versión ( 15.x ) a través del menú ''Administrar paquetes NuGet'' y eso lo solucionó.

También eliminé las referencias del proyecto existente primero, pero esa parte podría depender de lo que necesites.

Simplemente corre con los trucos .

Nada va a funcionar correctamente sin una referencia DLL adecuada. El siguiente problema solucionó el mismo problema que tuve durante 5 días, ya que estaba arruinando mi tiempo.

Coloque los DLL a continuación en la carpeta bin de su proyecto y proporcione una referencia a la solución completa para todos los DLL. Si surge un error como "No se pudo dar la referencia", ignórelo y omita esa DLL para que no proporcione una referencia. En su lugar, coloque también el error al crear una DLL en la carpeta bin que el proyecto tomará automáticamente durante la compilación.

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

Las dll anteriores se pueden encontrar en la ruta a continuación si el sistema está instalado con MTM o TFS

Ruta: C: / Archivos de programa (x86) / Microsoft Visual Studio / 2017 / Enterprise / Common7 / IDE / CommonExtensions / Microsoft / TeamFoundation / Team Explorer