[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

   

[EVENTO] Conclusiones sobre la mesa redonda sobre gestion del código fuente en MadridDOtNet

image

Buenas,

anoche estuvimos con los amigotes de MadridDotNet en las oficinas de AulaVulcan hablando de nuestras experiencias con las herramientas para la gestión de código fuente. Si bien el ambiente era bastante heterogéneo (todos con tecnologías Microsoft), confirmé que una vez más en este aspecto no hay soluciones mágicas que apliquen a todos los escenarios.

Hablamos de bastantes cosas, desde herramientas hasta Moles, pero para resumir dejo los siguientes puntos:

Herramientas de control de código fuente

En este punto hubo 2 herramientas que se utilizaban: Visual Source Safe y Team Foundation Server 2010.

Si bien es una herramienta que da muchos problemas, no tiene soporte y es bastante pobre todavía hay muchos VSS en el mundo. Yo comenté mis nefastas experiencias con SubVersion y la verdad me hubiese gustado escuchar a alguien que utilice GIT o Mercurial de manera más frencuente para tener una opinión válida del mundo de los DVCS.

Estrategias de Branching

Parece imposible pero todavía en el 2011 y todavía existen equipos que no tienen definida una estrategia de Branching. Si nunca has visto este tema y no sabes de que va, pues la Visual Studio TFS Branching Guide 2010 de Codeplex, seguro que te abre los ojos. Si en cambio ya sabes de que va el tema, como era el caso de @javierholguera pues aquí la cosa se pone más interesante.

Javi y su compañero nos comentaron como era su estructura actual de código fuente y comentaron un caso interesante > “No hacen un full branch para las ramas donde trabajan”. A primera vista esto puede parecer un poco ilógico, pero despues de ver un poco el modelo de negocio con el que se manejan, pues la cosa tiene bastante sentido, aunque claro también nos comentaron que cuando hacen los MERGEs tienen cuidado especial.

Miedo al MERGE (más que a la crisis !!!)

Esto lleva otro tema > mucha gente le tiene miedo a los MERGE. Personalmente yo creo que la acción de merge no es mala, es más, prefiero enfrentarme a los merge lo antes posible porque eso significa que estoy integrando trabajo en early stages. Cuanto más frecuentes sean los merges menos problemáticos serán los mismos. Aunque claro, eso es solo mi opinión y no es lo mismo hacer Merge con la herramienta que trae por defecto Visual Studio 2010 que con WinMerge.

¿Debemos mantener los históricos?

Sobre la marcha y relacionado con el tema anterior también surgió el tema de si era necesario mantener o no los históricos en el Source Control. A mi el instinto me dice que no destruya nunca nada, pero claro “cada bit se paga en €uros” y cuando trabajas con soluciones grandes, o tienes muchas ramas, pues esto se paga en espacio en disco, backup, etc.

El tema también estaba relacionado con la forma de trabajo de los equipos > “siempre hacemos un Get Latest de todo el Source Control en local y claro, eso es mucho”; aquí Luis (@lfraile) sugirió la posibilidad de configurar los Workspaces utilizando Cloack en los mismos para no tener que descargar todo (sobre esto escribí hace más de 2 años aquí) y quedó como una solución. Aunque yo no descarto educar un poco al equipo de trabajo y solo descargar lo que necesito para trabajar, esta es una de las ideas principales en las que se basan los Workspaces en Team Foundation Server.

CheckOut exclusivo > good or evil

Pues en el medio de checkin/checkout, workspaces, source control y demás, no podía dejar de aparecer el clásico y popular > “CheckOut exclusivo”. Aquí @javierholguera, Gisela, Jorge y otros estaban a favor de habilitar el checkout exclusivo para evitar problemas de MERGE, especialmente en archivos de proyectos donde el auto merge hace verdaderas obras de arte en Visual Studio.

Yo defendí mi posición “anti checkout exclusivo”, pero como no había cervezas de por medio apostadas, pues decidí no darle más vueltas, aunque veo que si bien es un cambio muy agradable incorporado en TFS2005, hay personas que prefieren trabajar con modo “lock”.

Organización de la estructura del Source Control

La última para no hacer de un post un libro, comentaré sobre otro tema que está atado a todo lo demás > “Cómo organizo mis soluciones?” aqui Javier comentó escenarios complejos de organización teniendo en cuenta proyectos de bases de datos, fachadas de servicios, etc. Un escenario interesante que se planteó fué el de como llevar adelante el desarrollo de productos que utilicen varias bases de datos SQL Server y cada una de ellas gestionada con proyectos dbproj. El problema surgía cuando nuevos productos compartían parte de un schema en una DB existente y se quería lograr tener integración contínua en las builds utilizando los proyectos de db para 2 productos diferentes. Básicamente se estaba mezclando por un lado funcionalidad de negocio en una misma base de datos, pero si se separaba quedaba un tanto complicado el proceso de CI. La solución: pues no hay ninguna de libro, aqui toca adoptar un modelo y ver si el mismo funciona Open-mouthed smile

 

Links, herramientas y otras cosillas para revisar

Finalmente dejo un pequeño listado de cosillas para ver que surgieron durante el evento:

 

Conclusión

Finalmente yo creo que lo mejor es lo siguiente:

  1. Formación
    1. Conocer las capacidades de las herramientas
    2. Conocer la problemática del negocio
  2. Tomar una decisión para comenzar a trabajar
  3. Cada 6 semanas/meses ajustar la forma de trabajo
  4. Go To 2

Update: me he olvidado de hablar un poco de la charla de café con las magdalenas y los cafecitos que nos tomamos después !!! Lo siento Open-mouthed smile. Obviamente esto fué lo mejor

 

Saludos @ Here

El Bruno

   

[TEAMBUILD2010] HowTo: Crear una Custom Activity para Team Build 2010

image47dd1de4

Buenas,

el siguiente tutorial muestra como crear una actividad personalizada para Team Build para Team Foundation Server 2010. En este caso concreto una actividad para mostrar información en el log de la ejecución de una build.

Tutorial

1. Creamos un nuevo proyecto del tipo Class Library. En este caso lo llamo [ElBruno.TeamBuild]

2. Agregamos las siguientes referencias:

  • System.Activities
  • Microsoft.TeamFoundation.Build.Workflow.dll
  • C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Build.Client.dll
  • C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.Client.dll
  • C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\ReferenceAssemblies\v2.0\Microsoft.TeamFoundation.VersionControl.Client.dll

Aclaración: Si bien inicialmente no utilizaremos todas las referencias, dejo este post de ejemplo para futuras referencias.

3. A continuación vamos a agregar algo de código en el proyecto. Primero borramos la clase [Class1.cs], agregamos un directorio llamado [Activities] y agregamos un nuevo elemento del tipo [Code Activity] llamado [DisplayInformation]

image

 

4. En la clase definimos 2 parámetros para la actividad:

  • Message, el mensaje a mostrar en el Log.
  • MessageImportance, el nivel de importancia del mensaje.

En el override Execute() utilizamos la funcion TrackBuildMessage() para mostrar esta información:

   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 DisplayInformation : CodeActivity

   9:     {

  10:         [RequiredArgument]

  11:         public InArgument<string> Message { get; set; }

  12:         [RequiredArgument]

  13:         public BuildMessageImportance MessageImportance { get; set; }

  14:  

  15:         protected override void Execute(CodeActivityContext context)

  16:         {

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

  18:             context.TrackBuildMessage(textIn, MessageImportance);

  19:         }

  20:     }

  21: }

5. Compilamos el proyecto y ya tenemos nuestra actividad para utilizar desde TFS2010.

6. Para tener acceso a esta actividad desde el editor de Visual Studio 2010, iremos por el camino fácil > copiaremos la dll compilada en el directorio de ensamblados de Visual Studio 2010:

[C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\]

Aclaración: Existe un método más elegante para probar esta actividad, eso lo explicaré en un futuro post.

7. Una vez copiado ya podemos utilizar esta actividad desde una definición de Build en Team Foundation Server 2010. Antes de modificar el template de ejecución de Builds, crearemos una copia del mismo y agregaremos el ensamblado a una ubicación específica del Source Control de TFS2010. En este caso en la ubicación

$//<TeamProjectName>/BuildDemo

8. Dentro de esta ubicación subimos los ensamblados compilados del proyecto

  • ElBruno.TeamBuild.dll
  • ElBruno.TeamBuild.pdb

9. Desde la ubicación de los templates de Team Foundation Server 2010, usualmente en [$/<TeamProjectName>/BuildProcessTemplates] copiamos el archivo [DefaultTemplate.xaml] al directorio [BuildDemo]. Una vez subidos todos los archivos, debería quedar similar a la siguiente imagen:

image

 

10. Creamos una definición de Build (que compile un proyecto cualquiera) y a continuación modificaremos la plantilla de build que utiliza esta definición. Para este ejemplo, he creado una build llamada [BlogCustomActivities].

image

 

11. En la sección [Process] editamos el Build Template con el que trabaja la build. Seleccionamos [New] y en el formulario de configuración seleccionamos el template que hemos copiado en el paso 7.

image

 

12. Lanzamos una build para ver que la misma funcione correctamente. No deberíamos tener ningún problema:

image

 

13. En este punto editaremos la plantilla de ejecución de la Build para utilizar la actividad que hemos creado en los primeros pasos. Editamos la plantilla que hemos copiado en el paso 7. Deberiamos ver el editor de WF como muestra la siguiente imagen:

image

 

14. Dentro de la Toolbox, agregamos una nueva sección llamada [Custom Build Activities] y agregamos nuestra actividad en la misma.

image

 

15. Agregamos una actividad de este tipo al inicio de la build, como tiene una propiedad pública requerida veremos que el editor marca un error de diseño:

image

 

16. Completamos la propiedad [Message], en este caso además cambio la importancia por el valor [High]

image

 

17. Protejemos la plantilla [DefaultTemplate.xaml]

18. A continuación debemos modificar el Build Controller que orquesta la ejecución de las builds. Para esto seleccionamos el nodo [Builds] desde el Team Explorer, desplegamos el menú contextual y seleccionamos la opción [Manage Build Controllers]

image

 

19. Desplegamos las propiedades del mismo, y configuramos la opción [Version control path to custom assemblies: ] indicando en el mismo el path donde hemos subido los ensamblados de la custom activity.

image

Aclaración: esta accíón reinicia el Build Controller, con lo que el mismo no estará disponible inmediatamente.

20. Lanzamos una nueva build de este tipo y ya podremos ver el mensaje personalizado en el log de ejecución de la misma.

image

 

Pues como introducción a actividades personalizadas, creo que me sirve. En próximos posts un par de escenarios más complejos Open-mouthed smile

 

Saludos @ Home

El Bruno

   

[VS2010] .REG para cambiar la acción por defecto de “Resolve” a “associate” en Visual Studio 2010

image47dd1de4

Buenas,

hace un tiempo el amigo Luis nos mostraba la entrada en el registro de windows que debemos cambiar para cambiar la acción por defecto de “Resolve” a “Associate” cuando hacemos un CheckIn con Visual Studio 2010.

Dentro de la ruta:

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\TeamFoundation\SourceControl\Behavior,

es necesario cambiar a False el valor de la clave:

ResolveAsDefaultCheckinAction

Como tengo muy poca memoria yo, me lo recuerdo en este post y además me adjunto un .reg que hace este trabajo por mi automáticamente.

http://cid-bef06dffdb192125.office.live.com/embedicon.aspx/Code%20Samples/20110320%20VS2010%20Change%20To%20Associate%20CheckIn%20Default%20Action.zip

 

Saludos @ Home

El Bruno