[TEAMBUILD2010] HowTo: Avoid element validation in Design Time in Team Build workflow editor

image47dd1de4

Buenas,

desde hace un par de días tengo pendiente poner un post que me trajo algunos dolores de cabeza pero qué, como no posee una solución oficial, pues no creía conveniente postearlo. Asi que quedas advertido, LA SOLUCIÓN AQUÍ PROPUESTA NO ESTÁ SOPORTADA.

El escenario es el siguiente:

Cuando editas una definición de Team Build, que es básicamente un workflow de WF, el IDE de Visual Studio 2010 se pone extremadamente lento.

No entraré en detalles de porqué se pone lento o pesado el IDE, ya que me puedo ganar un par de enemigos (y algunos son grandotes) pero una solución parcial para este problema es la siguiente:

Desactivar la validación de los elementos de un modelo de WF, cuando se trabaja sobre el mismo.

Si tienes 2 dedos de frente, verás que esto es un poco peligroso, ya que no te enteras de los errores hasta que ejecutas el workflow, pero si tu vida es una catarata de emoción constante y la adrenalina es tu bebida favorita, modifica esta entrada en el registro y done !!!

En la clave [HKEY_CURRENT_USER\Software\Microsoft\.NETFramework\v4.0.0.0\System.Activities.Presentation] crear una entrada llamada [DisableValidateOnModelItemChanged] de tipo REG_DWORD con valor = 1

image

image

Saludos @ Here

El Bruno

   

[TFS2010] HowTo: Cambiar el parent de un Branch (yahooooo!!!)

image47dd1de4

Buenas,

como lo tengo un poco abandonado en el blog, hoy voy a escribir sobre Team Foundation Server 2010, pero sin código ni nada > solo grafiquitos y un poco de tutorial. El escenario es el siguiente:

Teniendo el siguiente esquema de Branches

  • Main
    • DevA (branch desde Main)
    • DevB (branch desde Main)

que visto en el visor de TFS2010, se ve de la siguiente manera:

image

 

se plantea la siguiente cuestión:

¿Es posible reordenar los branches para que queden con la siguiente estructura?

  • Main
    • DevB
      • DevA

Pues a simple vista no es muy fácil (en TFS2008 imposible), pero existe una forma de hacerlo.

Tutorial

1. El comando para cambiar el padre de una rama en TFS2010 es el siguiente:

File // Source Control // Branching and Merging // Reparent

image

Sin embargo esta opción solo nos presenta esta opción si la lanzamos desde la rama DevA

image

 

2. En primer lugar tenemos que realizar un baseless merge (I’m sorry) utilizando el comando merge desde la línea de comandos para poder generar una relacion entre DevA y DevB, con el siguiente formato

tf merge /baseless <parent branch> <child branch>

3. Abrimos el Visual Studio 2010 Command Prompt y ejecutamos el comando, por ejemplo:

image

 

4. Veremos que existe una opcion pendiente de cambios en el Source Control Explorer, consolidamos los mismos (checkin)

image

 

5. En este punto volvemos ha realizar un Reparent de la rama DevA, como en el punto 1 y veremos una nueva opción disponible

image

 

6. Seleccionamos DevB como en nuevo “parent” del branch DevA y aplicamos los cambios. Si refrescamos el gráfico de las jerarquías de las ramas veremos que las mismas se han “reorganizado” de la siguiente forma:

image

 

7. Si analizamos el histórico de algun elemento que haya “viajado” por las 3 ramas, veremos como se muestran los Merge comunes y los Baseless Merge con otro tipo de línea.

image

 

apuntado !!!

 

Saludos @ Home

El Bruno

   

[TFS2010] MOVIENDO/SINCRONIZANDO CONTENIDOS ENTRE DIFERENTES TEAM PROJECTS (II)

image47dd1de4

Buenas,

hace un par de días escribí un post donde comenté como se podía utilizar TFS Integration Platform para sincronizar/mover contenidos entre 2 Team Projects. El ejemplo era bastante simple:

Copiar contenidos desde Tailspin Toys hacia TPA

El resultado fué un éxito (cosa simple cuando hay pocos datos a mover), y el post de hoy aprovecha ese punto de partida para dar solución a otro escenario

¿Qué sucede si se han generado nuevos contenidos o se han modificado contenidos en Tailspin Toys?

Pues la solución es utilizar el mismo proyecto de integración que utilizamos en el post original. Por ejemplo, si analizamos los cambios en los WorkItems podremos ver que el WorkItem 24 ha sufrido algunos cambios en el Team Project de origen:

image

De la misma forma, el archivo de la solución [Tailspin Toys\Development\Iteration 2\TailspinToys.sln] ha sufrido algunas modificaciones en el Team Project de origen:

image

Ahora bien, si lanzamos nuevamente el proyecto de sincronización desde la herramienta de TFS Integration Platform, podremos ver que en el proceso de Discovery > Analysis > Migration, hay nuevos elementos que se migran desde el Team Project de origen al Team Project de destino. De 30/113 elementos iniciales, ahora estamos en 31/121.

image

Si vemos el resultado de la migración, que ahora es más bien sincronización entre Tailspin Toys y TPA, veremos que la solución incluye el último cambio efectuado en el Source Control:

image

y el WorkItem 99 relacionado con el WI 24, tambien ha incorporado los cambios en su histórico:

image

En el próximo post, como utilizar una agenda para tener este proceso “casi automático”.

 

 

Saludos @ Home

El Bruno

   

[VS2010] HowTo: Configurar WinMerge como herramienta por defecto para analizar diferencias y realizar merge entre archivos

image47dd1de4

Buenas,

hoy toca destapar un par de post de la lista de borradores, en este caso los pasos para utilizar WinMerge como la herramienta por defeto para analizar diferencias entre archivos en Visual Studio 2010.

Tutorial

1. Primero lo más obvio; descargar la última versión disponible desde http://winmerge.org/

2. Abrir Visual Studio 2010

3. Acceder al menu [Tools // Options]

image

4. Presionar el botón [Configure User Tools]

5. Seleccionamos la opción [Add]

6. Agregamos la opción de Comparar, pero en este caso utilizando WinMerge utilizando los siguientes valores:

  • Extension: .*
  • Operation: Compare
  • Command: C:\Program Files (x86)\WinMerge\WinMergeU.exe
  • Arguments: /e /x /s /wl /dl %6 /dr %7 %1 %2

image

7. Confirmamos la configuración con [OK]

8. Agregamos la opción de Merge, utilizando WinMerge utilizando los siguientes valores:

  • Extension: .*
  • Operation: Merge
  • Command: C:\Program Files (x86)\WinMerge\WinMergeU.exe
  • Arguments: /e /s /x /ub /dl %6 /dr %7 %1 %2 %4

image

9. Confirmamos la configuración con [OK]

10. Deberíamos ver la configuarción completa similar a la siguiente:

image

11. Done !!!

 

Saludos @ Home

El Bruno

   

[TEAMBUILD2010] Error:CSC: Cannot specify /main if building a module or library

image47dd1de4

Buenas,

me dejo un apunte relacionado con un error que me he encontrado un par de veces en definiciones de Builds para Team Foundation Server 2010. Todavía no tengo claro si es un bug de Visual Studio 2010 o un error mío de definición de proyectos, aunque la tendencia es claramente para la 2da opción.

El error en cuestión es el siguiente:

CSC: Cannot specify /main if building a module or library

cuando se intenta compilar una Class Library en una build.

image

Obviamente esto es bastante incoherente, ya que una CL no puede tener un punto de entrada [main]. Sin embargo, analizando el archivo de proyecto .csproj veo que el mismo tiene definido un valor para el <StartUpObject>.

   1: <PropertyGroup>

   2:   <ProjectType>Local</ProjectType>

   3:   <ProductVersion>8.0.30319</ProductVersion>

   4:   ...

   5:   <StartupObject>BlaBlaBla.Test</StartupObject>

La solución es muy simple > eliminar este valor y ejecutar nuevamente la build.

Aclaración: el proyecto es migración de VS2003 a VS2010, con lo que el Product Version también es inválido.

 

Saludos @ Here

El Bruno

   

[TFS2010] Moviendo/sincronizando contenidos entre diferentes Team Projects (I)

image47dd1de4

Buenas,

otro de los temas que surgió en la mesa redonda el miércoles con los chicos de MadridDotNet, estaba relacionado con la necesidad de mover contenidos desde un Team Project hacia otro Team Project. Si bien la plataforma de integración desarrollada por los Visual Studio ALM Rangers: TFS Integration Platform, no resuelve al 100% el problema, si nos permite mover/sincronizar los elementos del Source Control y los WorkItems entre 2 TPs.

En el siguiente paso a paso, demostraré como sincronizar los contenidos del Team Project [Tailspin Toys] que viene de ejemplo en las máquinas virtuales de Trial de Team Foundation Server 2010 hacia otro Team Project llamado [TPA].

Tutorial

1. Descargamos e instalamos la última versión de TFS Integration Platform desde CodePlex

2. Lanzamos la aplicación [TFS Integration]

image

3. Creamos un nuevo proyecto de integración seleccionado la opción [Create New]

4. Entre las plantillas de proyecto, ubicadas en

[%Program Files%\Microsoft Team Foundation Server Integration Tools\Configurations\Team Foundation Server]

seleccionamos [VersionControlAndWorkItemTracking.xml] que nos permitirá sincronizar contenidos del Source Control y WorkItems.

5. En este momento podremos ver en el formulario de configuración del proyecto que debemos completar los siguientes elementos:

  • Nombre del proyecto
  • Tipo de sincronización
  • Origen del Source Control
  • Destino del Source Control
  • Origen de los WorkItems
  • Destino de los WorkItems

6. Para este post, he definido el nombre como “Post01” y el tipo de sincronización como “One-way migration”.

7. En la sección [Version Control Selection // Left Source] seleccionamos el proveedor para conectarnos con TFS2010.

image

8. Seleccionamos el Team Project [Tailspin Toys] desde la colección correspondiente:

image

9. En la sección [Version Control Selection // Right Source] seleccionamos el proveedor para conectarnos con TFS2010 y a continuación el Team Project [TPA].

10. En este punto podemos definir los elementos del Source Control que queremos sincronizar desde un TP a otro. En este caso moveremos todo el contenido del Left Source en [Tailspin Toys] hacia una rama llamada [TfsSync] en el Team Project [TPA].

Seleccionamos esta rama:

image 

11. El mapeo del source control debería quedar similar a la siguiente imagen:

image

12. A continuación definiremos las opciones para la migración de WorkItems. En la sección [WorkItem Tracking Section // Left Source] seleccionamos el proveedor para TFS2010 y seleccionamos el Team Project [Tailspin Toys].

13. En la sección [WorkItem Tracking Section // Right Source] seleccionamos el proveedor para TFS2010 y seleccionamos el Team Project [TPA].

14. La configuración debe quedar similar a la siguiente imagen:

image

15. En la sección queries podemos definir un filtro específico para definir los WorkItems que deseamos sincronizar. Para este ejemplo, utilizaremos la opción por defecto que migra todos los elementos entre los 2 Team Projects.

16. Guardamos la configuración en la base de datos.

17. Lanzamos la sincronización con la opción [Current Migration // Start]. Esta opción nos muestra el formulario de sincronización, en el que podremos ver el progreso de la misma. Por ejemplo:

image

18. Una vez que se han descubierto los elementos a migrar, se procede a analizar el contenido de los mismos para ver si existe algún error potencial:

image

19. Finalizados los procesos de Discovery y Analysis, se procede a la migración:

image

20. Una vez finalizada la migración, podremos ver el resultado  la misma. En este punto es recomendable ver el Log de migración para comprender mejor el detalle de lo que realiza la herramienta.

image

21. Si dentro del Team Project [TPA] vemos el contenido del Source Control, veremos que se han importado los elementos desde el otro Team Project.

image

22. En el histórico de un elemento, podremos ver que se han replicado los elementos del histórico original del Team Project de origen y además en el comentario, se ha agregado información del proceso de migración/sincronización.

image

23. De la misma forma, si analizamos los WorkItems migrados, podremos ver que en el histórico de los mismos aparece la información histórica de los WI originales. En este caso, la User Story 99 del Team Project [TPA], se corresponde con el WorkItem 24 del Team Project [Tailspin Toys]. En el histórico podremos ver la referencia entre los mismos.

image

Hasta aquí un pequeño tutorial para la sincronización de datos entre 2 TPs, en el próximo post un poco más de información al respecto.

 

Saludos @ Home

El Bruno

   

[TEAMBUILD2010] Mostrando Errores y Warning en los logs de Team Build

image47dd1de4

Buenas,

hace un par de días escribí un post donde comenté los pasos necesarios para crear una actividad personalizada para Team Build 2010. La actividad de ejemplo que creé en el post, mostraba un mensaje en el log de ejecución de una Build utilizando la función TrackBuildMessage(). Hoy crearé 2 nuevas actividades para mostrar mensajes de Warning y de Error, utilizando TrackBuildError() y TrackBuildWarning().

Como el funcionamiento de las 3 clases es bastante similar, he refactorizado un poco las mismas con la siguiente estructura final:

image

 

Y por ejemplo, el código de la clase DisplayWarning es el siguiente:

   1: using System.Activities;

   2: using Microsoft.TeamFoundation.Build.Client;

   3: using Microsoft.TeamFoundation.Build.Workflow.Activities;

   4:  

   5: namespace ElBruno.TeamBuild.Activities

   6: {

   7:     [BuildActivity(HostEnvironmentOption.All)]

   8:     public sealed class DisplayWarning : DisplayBase

   9:     {

  10:         protected override void Execute(CodeActivityContext context)

  11:         {

  12:             var textIn = context.GetValue(Message);

  13:             context.TrackBuildWarning(textIn);

  14:         }

  15:     }

  16: }

Si editamos una definición de build y agregamos las nuevas actividades:

image

 

veremos en la ejecución de la build los siguientes mensajes en el Log:

image

 

 

Saludos @ Here

El Bruno