[TFS2010] HowTo: Create a field for a WorkItem with custom values, and easy to maintain

image47dd1de4

Good,

before starting to explain a simple way to modify the definition a WorkItem Type, comes the disclaimer:

It is always advisable to think about it 20 times before modifying processes guide or template of a Team Project, in other words: does not modify it because 95% of cases, the templates by default are sufficient.

Now that we have already laid the foundations, we are going to a specific scenario:

Need to add a combo to a workitem, for example a Bug, and that the values of the same are easy to edit and maintain.

To do this, we will use the Team Foundation Server Power Tools, and modify the definition of a Bug to give solution to the previous stage.

Tutorial

1. From Visual Studio 2010, access to the menu [Tools / / Process Editor / / Global List / / Open Global List from Server]. If we were not connected to a TP, because at this time we will have to connect.

2. In the form of editing, display the contextual menu and select the [new Global list]

image

3 Using the options from the editor, in this case I created a new list called [ExtendedBoolean] with the following values:

image

4. Once finished editing the list, press [OK]. This action saves changes in the global definition of items on the server ofTFS2010.

5 And now plays edit the definition of a Bug, so select the option [Tools / / Process Editor / / Work Item Types / / Open WIT from Server].

6 Select the appropriate Team Project and then the type of WorkItem that we want to modify.

image

7. In the WorkItem Type editing form, [Fields] tab create a new field called [ExtendedBoolean], of type String, with the following values.

image

8 Select the tab [Rules] and add a new rule of the type [ALLOWEDVALUES]

image

9. This will open the form for editing of the values that will support the WorkItem Field. In this case, click on [New] and select the global list we created in the previous steps.

image

10 Add the new field, the visual interface of edition of the WorkItem (as I have explained in detail in this post) and we can already see the combo with the values of the global list.

image

11 If we need to modify these values, rather than changing the definition of the WorkItem, we simply modify the global list.

Greetings @ Home

The Bruno

   

[TFS2010] HowTo: Crear un campo para un WorkItem con valores personalizados y de fácil mantenimiento

image47dd1de4

Buenas,

antes de comenzar a explicar una forma sencilla de modificar la definición un WorkItem Type, llega el disclaimer:

Siempre es recomendable pensarlo 20 veces antes de modificar la guía de procesos o plantilla de un Team Project, en otras palabras: no lo modifiques porque en el 95% de los casos, las plantillas por defecto son suficientes.

Ahora que ya hemos sentado las bases, vamos a un escenario concreto:

Necesidad de agregar un combo a un workitem, por ejemplo  un Bug, y que los valores del mismo sean fáciles de editar y mantener.

Para esto, aprovecharemos las Team Foundation Server Power Tools, y modificaremos la definición de un Bug para dar solución al escenario anterior.

Tutorial

1. Desde Visual Studio 2010, acceder al menú [Tools // Process Editor // Global List // Open Global List from Server]. Si no estábamos conectados a un TP, pues en este momento tendremos que conectarnos.

2. En el formulario de edición, desplegar el menú contextual y seleccionar la opción [New Global List]

image

 

3. Utilizando las opciones del editor, en este caso he creado una lista nueva llamada [ExtendedBoolean] con los siguientes valores:

image

 

4. Una vez terminada de editar la lista, presionar [OK]. Esta acción guarda los cambios en la definición global de elementos del servidor de TFS2010.

5. Ahora toca editar la definición de un Bug, para esto seleccionamos la opción [Tools // Process Editor // Work Item Types // Open WIT from Server].

6. Seleccionamos el Team Project correspondiente y luego el tipo de WorkItem que queremos modificar.

image

 

7. En el formulario de edición del WorkItem Type, en la pestaña [Fields] creamos un nuevo campo llamado [ExtendedBoolean], de tipo String, con los siguientes valores.

image

 

8. Seleccionamos la pestaña [Rules] y agregamos una nueva regla del tipo [ALLOWEDVALUES]

image

 

9. Esto abrirá el formulario de edición de los valores que soportará el WorkItem Field. En este caso, presionamos [New] y seleccionamos la lista global que hemos creado en los pasos anteriores.

image

 

10. Agregamos el nuevo campo, a la interfaz visual de edición del WorkItem (lo he explicado en detalle en este post) y ya podremos ver el combo con los valores de la lista global.

image

 

11. Si necesitamos modificar estos valores, en lugar de modificar la definición del WorkItem, simplemente modificamos la lista global.

 

Saludos @ Home

El Bruno

   

[VS2010] HowTo: Differentiate the same solution in different branches (thanks VSCommands2010)

image47dd1de4

Good,

When you work with any strategy of Branching (but do you, out of my blog! should) is very common that you are opening the same solution in the branch of development evolutovo and in the branch of maintenance or corrective.

The following example shows how we have the solution ClassLibrary1 and the files in the branches [DEV] and [MAIN]

image

The problem often come when you open a solution, for example the DEV branch and you despistas and you get to change it as if it were that of the MAIN branch.

A useful way of differentiating the elements of each branch, is to take advantage of a new feature of the 2010 VSCommands for Visual Studio 2010 that lets you define a “friendly name” for solutions. To work with this feature, select the solution and see the properties of the same, where we will see 2 new properties.

image

Property [friendly name solution path Reg] we define a regular expression in which we can create one or more groups that we can then use in property [friendly name] to make use of them. In this case, the group is called {BranchName}and show it after the name of the solution.

Open the solution from the DEV branch you see that this description applies to the title of the window and also in thesolution Explorer.

image

If you instead open the solution from the MAINbranch, we will see the description for this branch.

image

For more information about the VSCommands 2010http://vscommands.com/features/

Greetings @ Here

The Bruno

   

[VS2010] HowTo: Diferenciar la misma solución en diferentes ramas (thanks VSCommands2010)

image47dd1de4

Buenas,

cuando trabajas con cualquier estrategia de Branching (sino lo haces, fuera de mi blog !!! deberías) es muy usual que te encuentres abriendo la misma solución en la rama de desarrollo evolutovo y en la rama de mantenimiento o correctivo.

El siguiente ejemplo, muestra como tenemos la solución ClassLibrary1 y los archivos propios de la misma en las ramas [DEV] y [MAIN]

image

El problema suele venir cuando abres una solución, por ejemplo de la rama DEV y te despistas y te pones a modificar la misma como si fuese la de la rama MAIN.

Una forma útil de diferenciar los elementos de cada rama, es aprovechar una nueva feature de la VSCommands 2010 para Visual Studio 2010 que permite definir un “friendly name” para las soluciones. Para trabajar con esta feature, seleccionamos la solucion y vemos las propiedades de la misma, donde veremos 2 nuevas propiedades.

image

En la propiedad [Friendly Name Solution Path Reg] definimos una expresión regular en la que podemos crear uno o más grupos que luego podemos utilizar en la propiedad [Friendly Name] para hacer uso de los mismos. En este caso, el grupo se llama {BranchName} y lo muestro después del nombre de la solución.

Si abrimos la solución desde la rama DEV veremos que esta descripción se aplica al título de la ventana y también en el Solution Explorer.

image

Si en cambio abrimos la solución desde la rama MAIN, veremos la descripcion correspondiente a esta rama.

image

Para más información sobre las VSCommands 2010: http://vscommands.com/features/

Saludos @ Here

El Bruno

   

[VS2010] Introduction to StyleCop

image47dd1de4

Good,

StyleCop is a tool that analyzes C source code # and applies a set of style and consistency rules. You can run from within Visual Studio or integrated into a project of TeamBuild. It is quite useful when you want to ensure that the “aesthetic of your code” is consistent among themselves as well as having a good design of the architecture of your solution, respect the rules of design SOLID. This post is based on the 4.5RC version which can be downloaded from here.

A detail to keep in mind is that during the installation of the product, you can select the integration with Visual Studio 2010and also if you want the necessary files for MSBuild to add validations of StyleCop for compilations of Team Build.

image

For this example, I selected the 2 options.

We are on the first example of code that let us see what says StyleCop thereon. If we create a class library project with your class by default we find the following code:

   1: using System;
   2: using System.Collections.Generic;
   3: using System.Linq;
   4: using System.Text;
   5:
   6: namespace StyleCopDemo01
   7: {
   8:     public class Class1
   9:     {
  10:     }
  11: }

And StyleCop tells us with 6 Warnings of the following details to take into account:

image

If we “move” the using within the Namespace, as indicated by the recent warnings, the code is in the following way:

   1: namespace StyleCopDemo01
   2: {
   3:     using System;
   4:     using System.Collections.Generic;
   5:     using System.Linq;
   6:     using System.Text;
   7:
   8:     public class Class1
   9:     {
  10:     }
  11: }

And actually, now we just have 2 warnings for those who worry about:

image

Add a bit of code over the example:

   1: public string Foo(int firstArgument, int secondArgument)
   2: {
   3:     var res = "no";
   4:     if (firstArgument == secondArgument)
   5:     {
   6:         res = "yes";
   7:     }
   8:     if (firstArgument > secondArgument)
   9:     {res = "maybe";}
  10:     return res;
  11: }

And now we’ll see how we have to worry about the fifth after the keys, the spaces between the elements between the keys, etc.

image

By default, StyleCop has enabled all the rules that have, which can be quite annoying; in particular with regard to the comments, as it not only recommend add tags in comments in all classes, but it also recommends headers in classes, sections of copyright, etc.

If you want to configure the set of rules with which we work, we can do so from the project in question. Select the same, deploy the contextual menu and select the option [StyleCop Settings]

image

In this form, we will see the different types of rules that apply during the analysis of StyleCop. My recommendation > disable those of documentation Open-mouthed smile

image

In the coming posts a little more about StyleCop and Team Build.

Greetings @ Here

The Bruno

   

[VS2010] Introduccion a StyleCop

image47dd1de4

Buenas,

StyleCop es una herramienta que analiza código fuente C# y aplica un conjunto de reglas de estilo y consistencia. Se puede ejecutar desde dentro de Visual Studio o integrado en un proyecto de TeamBuild. Es bastante útil cuando además de contar con un buen diseño de la arquitectura de tu solución, de respetar las reglas de diseño SOLID, quieres garantizar que la “estética de tu código” sea coherente entre sí. Este post se basa en la versión 4.5RC que se puede descargar desde aquí.

Un detalle a tener en cuenta es que durante la instalación del producto, puedes seleccionar la integración con Visual Studio 2010 y además si quieres los archivos necesarios para MSBuild para agregar validaciones de StyleCop durante compilaciones de Team Build.

image

Para este ejemplo, he seleccionado las 2 opciones.

Vamos por el primer ejemplo de código para que veamos lo que dice StyleCop al respecto. Si creamos un proyecto de bibloteca de clases con su clase por defecto nos encontramos con el siguiente código:

   1: using System;

   2: using System.Collections.Generic;

   3: using System.Linq;

   4: using System.Text;

   5:  

   6: namespace StyleCopDemo01

   7: {

   8:     public class Class1

   9:     {

  10:     }

  11: }

 

Y StyleCop nos avisa con 6 Warnings de los siguientes detalles a tener en cuenta:

image

Si “movemos” los using dentro del Namespace, como indican los últimos warnings, el código queda de la siguiente forma:

   1: namespace StyleCopDemo01

   2: {

   3:     using System;

   4:     using System.Collections.Generic;

   5:     using System.Linq;

   6:     using System.Text;

   7:  

   8:     public class Class1

   9:     {

  10:     }

  11: }

Y efectivamente, ahora solo tenemos 2 warnings por los que preocuparnos:

image

Agregamos un poco de código más al ejemplo:

   1: public string Foo(int firstArgument, int secondArgument)

   2: {

   3:     var res = "no";

   4:     if (firstArgument == secondArgument)

   5:     {

   6:         res = "yes";

   7:     }

   8:     if (firstArgument > secondArgument)

   9:     {res = "maybe";}

  10:     return res;

  11: }

 

Y ahora veremos como tenemos que preocuparnos por los espaciós después de las llaves, los espacios entre los elementos entre las llaves, etc.

image

 

Por defecto, StyleCop tiene activadas todas las reglas que posee, lo cual puede ser bastante molesto; en especial en lo referido a los comentarios, ya que no solo recomienda agregar tags de comentarios en todas las clases, sino que también recomienda headers en las clases, secciones de copyright, etc.

Si queremos configurar el set de reglas con el que queremos trabajar, podemos hacerlo desde el proyecto en cuestión. Seleccionamos el mismo, desplegamos el menú contextual y seleccionamos la opción [StyleCop Settings]

image

 

En este formulario veremos los diferentes tipos de reglas que se aplican durante el análisis de StyleCop. Mi recomendación > desactivar las de documentación Open-mouthed smile

image

 

En los próximos posts un poco más sobre StyleCop y Team Build.

 

Saludos @ Here

El Bruno

   

[TFS2010] TFS Workbench, a great tool to work with TFS workitems

image47dd1de4

Good,

today I have to recommend an excellent tool of our friends of ScrumForTeamSystemTFS WorkBench.

This tool can work with elements of a Team Project from Team Foundation Server 2010 and view them as if it were a work of PostIs Board.

With TFS WorkBench is possible

  • Drag and drop elements of work in the various lines of the same State
  • View and manipulate the links to the WorkItems through in the hierarchical view.
  • Create and edit multiple WorkItems simultaneously using the element list mode.

image

Really recommended.

Download: http://www.scrumforteamsystem.com/version-3/tfs-workbench-v2-2-x64

Greetings @ Home

The Bruno