visual-studio-2013 - tools - tfpt

Visual Studio 2013+TFS=lento

Question

Estoy usando una laptop recientemente reinstalada con SSD. Estoy usando Visual Studio 2013 con TFS.

Mi problema es que tengo que esperar entre 20 y 25 segundos cuando empiezo y cuando termino una fusión o comparación. El tiempo de espera para finalizar una sesión de depuración web también es de aproximadamente 30 segundos.

No tengo una configuración especial. El servidor TFS está en nuestra LAN y estoy conectado a través de ethernet. No tengo un proxy configurado en la configuración de TFS.

Ya probé lo siguiente:

• Archivos suo eliminados
• Configuración añadida a la configuración de la aplicación visual studio 2013 para deshabilitar el proxy.
• Almacenamiento de símbolos localmente
• Reasignaciones agregadas
• Espacio de trabajo re-agregado

No tengo este problema con proyectos que están fuera de TFS. Mis colegas no tienen este problema.

Answer 1

El problema con TFS es que se integra completamente con su IDE.

Sugiero usar GIT. Puede convertir su proyecto de tfs a git usando varias herramientas, por ejemplo git-tfs, consulte https://github.com/git-tfs/git-tfs/blob/master/doc/usecases/migrate_tfs_to_git.md

También hay una publicación en el blog sobre alguien que hace esto: https://chriskirby.net/blog/migrate-an-existing-project-from-tfs-to-github-with-changeset-history-intact

Answer 2

Hay una cantidad de opciones disponibles para usted que aún no ha probado:

Espacio de trabajo local frente al espacio de trabajo del servidor

Cuando tiene un espacio de trabajo grande (es decir, muchos archivos en su área de trabajo) o cuando su espacio de trabajo contiene muchos archivos binarios (paquetes NuGet por ejemplo), puede disminuir considerablemente cuando está configurado como un "Espacio de trabajo local". Los espacios de trabajo locales mantienen el archivo original (la versión más reciente como lo conoce su servidor TFS) en un archivo comprimido en el disco. Cada vez que cambian muchos archivos, se comparan con la última copia conocida y, en función de eso, se registran o se retiran.

Un espacio de trabajo de servidor, por otro lado, simplemente mira el bit ''de solo lectura'' de los archivos. Si tiene uno, TFS asumirá que no ha cambiado. Si no tiene uno, TFS supone que está desprotegido.

Los espacios de trabajo locales tienen sus ventajas, especialmente si trabaja mucho fuera de línea, pero pueden causar una grave desaceleración en los casos descritos anteriormente.

Intente configurar su espacio de trabajo como espacio de trabajo del Servidor para ver si eso elimina el problema.

Visual Studio, de forma predeterminada, crea un espacio de trabajo Local desde que se introdujo esta característica.

Elimine archivos binarios grandes y alcance el área de trabajo de forma adecuada

Si desea utilizar un área de trabajo local, puede necesitar actualizar su solución para asegurarse de que los paquetes NuGet no estén marcados, los archivos binarios grandes en su área de trabajo estén ocultos y solo capture los archivos que realmente necesita (por ejemplo, cree un nuevo espacio de trabajo). para diferentes ramas).

Para ocultar un archivo, edite su asignación de espacio de trabajo y agregue una carpeta que no desee recuperar y configure la acción de "activa" a "capa", o puede ocultarla directamente desde el menú contextual de Source Control Explorer, puede encuéntralo en Avanzado y luego en Capa .

En lugar de verificar sus referencias binarias, intente encontrar los paquetes NuGet correspondientes o créelos usted mismo. Los grandes archivos binarios son siempre una plaga cuando se trata de los sistemas de control de versiones, ya que nunca se pueden fusionar y básicamente se quedan allí sentados.

Corrupción de caché

El cliente Team Explorer mantiene un caché en la siguiente ubicación:

C: / Users {nombre de usuario} / AppData / Local / Microsoft / Team Foundation {version} / Cache

Que puede haberse corrompido por alguna razón. Borrar todas las subcarpetas y VersionControl.config puede ser un último recurso para que vuelva a funcionar.

Reparar Visual Studio y desactivar extensiones

A veces, Visual Studio puede confundirse un poco con todas las revisiones, service packs y otras cosas que se instalan. Para no mencionar todas las extensiones que pueden influir en su comportamiento.

Algunas extensiones pueden ralentizar seriamente las interacciones con el control de origen. Las extensiones antes mencionadas de Source Control Explorer, por ejemplo, tienen una opción para cambiar la fecha de los archivos en el disco, lo que puede provocar que las operaciones "Get" se detengan al final por varios segundos.

Desactivar tales extensiones para ver si el comportamiento aún existe sin ellas es siempre algo que debes hacer. Reparar Visual Studio y volver a aplicar el último paquete de actualización también es algo que puede resolver problemas como estos.

Las extensiones sospechosas incluyen aquellas que:

• Extiende el depurador
• Extienda Team Explorer
• Extienda el Source Control Explorer

Desactivar la detección automática de Windows Proxy

He visto un comportamiento extraño, no en todas las redes, no con todos los servidores proxy, cuando la detección automática de proxy de Windows está activada. La detección de proxy puede causar esperas largas ya que está tratando de averiguar a qué proxy conectarse.

Intente deshabilitar el script de proxy y la detección automática, si es dependiente de un proxy, intente configurarlo directamente en la pantalla de configuración de proxy clásica:

Intenta encontrar el problema de la manera más difícil

Habilite el rastreo del lado del cliente como se describe aquí . En devenv.exe.config incluye el siguiente fragmento. Va a volcar todo lo que sucede alrededor de TFS a un archivo de registro. Puede ser doloroso determinar qué está sucediendo, pero le dará mucha información:

<system.diagnostics>
<switches>
<add name="TeamFoundationSoapProxy" value="4" />
<add name="VersionControl" value="4" />
</switches>
<trace autoflush="true" indentsize="3">
<listeners>
<add name="myListener" type="Microsoft.TeamFoundation.TeamFoundationTextWriterTraceListener,Microsoft.TeamFoundation.Common, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" initializeData="c:/tf.log" />
<add name="perfListener" type="Microsoft.TeamFoundation.Client.PerfTraceListener,Microsoft.TeamFoundation.Client, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</listeners>
</trace>
</system.diagnostics>

Y puede ejecutar Visual Studio con el registro de seguimiento de actividad habilitado. Si hay un plugin que se comporta mal, a menudo da como resultado información en el ActivityLog.xml . Para habilitar este tipo de rastros, inicie Visual Studio con la opción /log desde la línea de comandos. El registro se eliminará aquí:

% AppData% / Microsoft / VisualStudio / 12.0 / ActivityLog.XML

En el peor de los casos, puede adjuntar un Visual Studio o un generador de perfiles (o la herramienta de línea de comandos de Intellitrace) a Visual Studio y recopilar un registro de cada cosa que ocurra dentro de Visual Studio.

Y podría intentar monitorear su sistema con Process Explorer para ver si el acceso a IO o a la red lo está desacelerando.

Answer 3

Tuve un problema muy similar con Win10 64bit. VS2015-TFS, etc. Lo resolví cambiando el plan de energía de las laptops de ''Ahorro de energía'' a ''Alto rendimiento'' ...