November 2008 - Artículos

Buenas,

esta es una de las herramientas que aquellos que utilizamos ReSharper, agradecemos que esté en Visual Studio Team System 2010. Se trata de un nuevo buscador inteligente integrado en el IDE de Visual Studio que realiza búsquedas sobre los elementos de nuestro proyecto.

El mismo se activa con la combinación CTRL+, y lo primero que podemos ver es una ventana en blanco:

 

Donde al momento de ir tecleando, aparecerán los elementos que coincidan con nuestro criterio de búsqueda. Por ejemplo, después de poner la letra a, vemos que nos aparecen 2 funciones y 2 archivos dentro de nuestra solución.

 

Si refinamos un poco más la búsqueda, con el texto Add, veremos que solo quedan las funciones que comienzan con ese texo.

 

Finalmente, podemos hacer búsquedas con pequeñas expresiones regurales, como por ejemplo todo lo que comience con Add y termine con Te: Add*Te

    

 

No hace falta decir que si hacemos doble click sobre alguno de los elementos que aparecen en el formulario de búsqueda, automáticamente podremos ir a los mismos en el IDE.

Pues ha llegado un poco tarde, pero ha llegado :D

 

Saludos @ Home

El Bruno

Crossposting from ElBruno.com

Buenas,

como ya he hablado un poco sobre varias novedades de Visual Studio Team System 2010, creo que es momento de recopilar las mismas en un pequeño listado (que nuestros amigos de habla inglesa seguramente titularían “What’s new in Visual Studio Team System 2010”)

WorkItems

Source Control

TFS Build

Herramientas de Modelado

Visual Studio

Visual Studio Test

Varios

 

Como todavía queda mucho material por comentar y muchos posts por crear, actualizaré este listado periódicamente.

 

Saludos @ Home

El Bruno

Crossposting from ElBruno.com

Buenas,

salvo en determinados escenarios, hoy el trabajo con XML se ha convertido en una constante para la mayoría de los desarrolladores. En este punto, las herramientas que incopora Microsoft Visual Studio 2008 son útiles pero es posible mejorarlas bastante. Visual Studio Team System 2010 incopora algunas novedades al respecto, pero comparados con productos de otras empresas todavía tiene mucho que mejorar.

Hoy le echaremos un vistazo al nuevo Schema Explorer y para basarnos en un ejemplo real, que mejor que traer un schema de la competencia y trabajar con el mismo; el schema en cuestion se puede descargar desde http://www.cduce.org/manual_schema_samples.html. A continuación un pequeño paso a paso para recorrer algunas de las novedades incorporadas en esta versión.

 

Tutorial

1. Una vez descargado el schema abrir el mismo desde Visual Studio Team System 2010 con el menú File // Open // File.

2. Podemos ver que además del panel XML Schema Explorer, dentro del IDE de VS existe un nuevo visor basado en WPF que nos permite inspeccionar de una manera un poco más amigable nuestro Schema XSD.

 

3. Dentro del panel XML Schema Explorer podemos ver que tenemos la opción de organizar los elementos del Schema de acuerdo a algun tipo de criterio: por nombre, por tipo o por el orden original del documento. Además de la opción de mostrar u ocultar los namespaces y los archivos.

 

3. Un detalle interesante es la capacidad buscar dentro del panel de una forma muy ràpida. Por ejemplo, podemos ingresar un texto de búsqueda y los elementos que coincidan con esta búsqueda dentro del schema, se resaltan con un color diferente.

 

4.  Dentro del nuevo visor, podemos ver una vista principal donde se muestran datos de alto nivel del schema como la cantidad de elementos globales, tipos simples y complejos. Existe además una sección superior, donde se presentan un par de ayudas para poder comenzar.

 

5. Existen además 2 nuevas vistas “Content Model View” y ”Graph View”; donde es posible ver los diferentes elementos del Schema en un modo gráfico, e ir analizando los diferentes elementos del schema. Por defecto estas vistas están vacías, es posible arrastrar elementos desde el panel XML Schema Explorer o incoporar desde elementos ya agregados.

 

6. Finalmente en la sección inferior podemos ver un pequeño “navegador” que nos muestra el rastro de migas del elemento seleccionado. Además, para ser un poco más ágiles, desde esta vista es posible volver al XML Schema Explorer, pasar al modo gráfico o ver el código xsd del mismo en el visor stándar de XML del IDE de Visual Studio.

 

En pocas palabras, el nuevo visor promete y bastante, ya que por ejemplo, frente a Schemas muy complejos podemos personalizar una o más vistas con los elementos que deseamos para tener un vistazo general de la estructura de un Schema.

 

Saludos @ Home

El Bruno

Crossposting from ElBruno.com

Buenas

ya bastante tiempo escribí sobre como aprovechar a Microsoft Visual Studio 2008 y Team Foundation Server 2008 para realizar acciones de Integración Continua y acercarnos un poco a Test Driven Development. Lamentablemente, el IDE de Microsoft Visual Studio 2008 carecía de algunas herramientas para poder trabajar en un modo TDD al 100%.

Visual Studio Team System 2010 incorpora muchas novedades y entre ellas la capacidad de trabajar en un contexto dirigido por pruebas. El siguiente ejemplo, muestra de una forma muy simple como podemos aprovechar las nuevas capacidades del IDE para alcanzar este objetivo.

Tutorial

1. En primer lugar creamos un proyecto de Test. Para este ejemplo, he escogido C# 4.0 como lenguaje y lo he llamado DemoTestProject

 

2. Este proyecto se crea inicialmente con una clase llamada UnitTest1.cs a la que renombraremos por CustomerManagerTest.cs.

3. A continuación dentro de la clase CustomerManagerTest.cs renombraremos el test TestMethod1 por TestValidateCustomerAddress.

[TestMethod] public void TestValidateCustomerAddress() { // // TODO: Add test logic here // }

4. Lo siguiente que necesitamos en nuestro test es crear un objeto de un tipo que todavía no existe, supongamos que deseamos una clase para validaciones de cliente llamada CustomerValidation. Como podemos ver en la siguiente imagen, al no existir esta clase, obviamente el compilador nos muestra un error.

 

5. Es en este punto donde el nuevo IDE nos comienza a ayudar un poco, ya que si notamos el smartTag que nos aparece debajo del error podremos ver las siguientes opciones (para mostrar las opciones podemos utilizar la combinacion CTRL+.)

 

6. Donde la opción [Generate Class for CustomerValidation] generará una clase llamada CustomerValidation dentro del proyecto actual, y la 2da opción [Generate Other…] nos permite seleccionar otro tipo de opciones.

 

7. Lamentablemente en esta release todavía no nos permiten seleccionar una opción al estilo “New Project in C#”, para crear la clase dentro del mismo. Asi que sin elegir ninguna opción crearemos un nuevo proyecto de tipo biblioteca de clases en C# llamado DemoTest y volviendo a nuestro test podremos ver que ya tenemos la opción de agregar la clase dentro del nuevo proyecto.

 

8. Una vez generada la clase, automáticamente se agrega la referencia al nuevo proyecto en nuestro proyecto de test y ya podremos ver que nuestro código compila correctamente. Pero esto no es todo, si seguimos nuestro ejemplo, donde nuestra prueba debe validar una dirección de mail, tal vez querramos agregar un código similar al siguiente:

 

9. Como vemos que el mismo no compila, podemos volver a la opcion CTRL+. para desplegar el menu de opciones y de esta forma automáticamente generar la implementación de la función que queremos testear.

 

10. Finalmente, una vez implementado, podremos ver que nuestro test ya compila correctamente y que por otra parte tenemos generada la “interfaz inicial” que nos permite seguir escribiendo nuestras pruebas.

 

Saludos @ Here

El Bruno

Crossposting from ElBruno.com

Buenas,

pequeño post recopilatorio con los posts, HowTos, posts sobre informes, builds, etc. sobre Team Foundation Server 2008 principalmente aunque algunos son comunes para Team Foundation Server 2005:

How To

Herramientas

Team System Web Access

TFS Errors

TFS Build

TFS WareHouse e Informes

Varios

 

Saludos @ Home

El Bruno

Crossposting from ElBruno.com

Buenas,

desde los tiempos de FxCop, aplicar reglas de análisis de código a nuestros proyectos siempre ha sido una buena idea. Con Microsoft Visual Studio 2008 y Team Foundation Server 2008 se solucionaron un par de problemas, ya que se podían definir set de reglas a nivel de Team Project, pero sin embargo seguía siendo un poco fastidioso el tener que armar estas colecciones de reglas (popularmente conocidos como RuleSet).

Visual Studio Team System 2010 nos ofrece nuevas posibilidades al respecto, donde una vez más, no se cambia el proceso; pero si la forma de trabajar. El siguiente ejemplo muestra algunas novedades incluidas en esta CTP relacionadas con la configuración y definición de RuleSet.

Ejemplo

1. La siguiente imagen muestra la ventana de propiedades de un proyecto en Visual Studio Team System 2010, en la pestaña de Code Analysis.

 

2. En el combo de opciones, tenemos la opción de seleccionar un archivo de reglas desde nuestro disco, o utilizar alguno de los distribuidos out of the box con Visual Studio.

Esta opción es una de las más interesantes ya que de esta forma, podemos asociar de una forma simple y rápida nuestros proyectos a un set de reglas contenido en un archivo.

 

3. El formulario de creacion de RuleSets, es también otra novedad e incluye varias novedades interesantes. Por ejemplo, la siguiente imagen muestra la edicion de un archivo llamado MyRuleSet.ruleset.

 

4. En la imagen se puede ver que en la edicion es posible agrupar por Id, Categoría, Nombre, Namespace, etc; además pudiendo aplicar un filtro de texto sobre el nombre de la regla

 

5. También es posible mostrar/ocultar las diferentes reglas de análisis, de acuerdo al nivel de tratamiento de las mismas: Error, Warning o None.

Adicionalmente, se ha incluido una opción muy interesante que permite mostrar solo las reglas de análisis de código que apliquen al tipo de proyecto sobre el que estamos trabajando. De esta manera, si estamos trabajando en un proyecto de Mobile, no veremos reglas que no corresponden.

 

6. Finalmente mencionar, que existe una posibilidad un tanto peligrosa delicada que nos permite crear un set de reglas, a partir de otros set de reglas existentes, y que pueden dar lugar a los clásicos includes que tanto sufrimos en ASP. Pero que con cuidado y paciencia seguro que nos dan excelentes resultados

 

 

 

 

Saludos @ Here

El Bruno

Crossposting from ElBruno.com

Buenas,

ayer comentaba sobre lo útil y práctico que es el nuevo editor de actividades para los proyectos de Build incluido en Visual Studio Team System 2010. Como lo mejor es dejar un par de pruebas del mismo, se me ocurrió que lo más simple es demostrar como ha cambiado el modelo, con dos tareas de las más comunes en un Build: selección de proyectos a compilar y de pruebas a ejecutar.

Ejemplo

1. No entraré en los pasos básicos de la creación de un proyecto de Build, ya que salvo la novedad de los Gated CheckIns, los siguientes formularios no han cambiado mucho.

Free Image Hosting at www.ImageShack.us 

2. En el paso de la definición del proceso, la selección de los proyectos y de las pruebas se realiza desde la ventana de propiedades de la actividad principal del proceso.

Adicionalmente se nos recuerda, que debemos seleccionar los mismos con pequeños links a estas propiedades

 

3. Cambiando un poco el modelo anterior, donde los paths eran relativos al sitio de ejecución del Build, en este caso la selección de las soluciones se realiza a través de un selector que permite navegar la estructura de directorios definida en el Source Control.

De esta forma, agregar uno o N soluciones, se convierte en una tarea trivial.

 

4. La selección de las listas de Tests a ejecutar, también se aprovechan de estas nuevas herramientas y la selección de una lista (que no es más que un archivo .vsmdi) se realiza con el asistente.

Sin embargo, si analizamos un poco el proceso y la información contenida en este archivo, tal vez necesitemos explotar un poco más el mismo, incluyendo solo algunas listas de tests específicas y en un orden determinado. Pues bien, el asistente nos permite importar el detalle de los archivos .vsmdi y organizar el mismo a nuestro antojo.

 

Como hemos visto en las imágenes anteriores, el proceso de definición de proyectos de Build se simplifica muchísimo. Y si bien es cierto que muchas de estas actividades, se pueden realizar actualmente con paciencia y un Notepad, yo si el editor es gráfico –> mejor !!!

 

 

Saludos @ Home

El Bruno

Crossposting from ElBruno.com

Buenas,

ya he comentado muchas de las novedades de Visual Studio Team System 2010, pero sin embargo esta es una de las que más me impactó cuando la vi por primera vez allá por Abril.

Antes de comentarla, un poco de historia. Si alguna vez has tenido que sufrir la edición de un Build, seguramente has llegado al punto de conocer el fabuloso xml que describe los targets y actions de un proyecto de Build. Cuando un Build es algo simple y trivial, el asistente de Visual Studio es suficiente, pero cuando quieres salirte un poco del molde, no queda más opción que editar en modo texto plano la definición del Build (tarea bastante tediosa y poco aconsejable para días con poca lucidez)

Por suerte Visual Studio Team System 2010 soluciona parcialmente este problema incoporando un editor para la definición de un proyecto de Build, que al ser un Build un proyecto secuencial de pasos se basa en Workflow Foundation.

Como se puede ver en la siguiente imagen, en la sección Process de la definición de un Build, ahora podemos ver las siguientes secciones:

  1. Editor de actividades
    Soportado internamente en WF, con una interfaz basad en un treeview.
  2. Toolbox con las actividades
    Contiene las actividades soportadas para el WorkFlow. Obviamente, los elementos de esta toolbox son extensibles y podremos crear nuestras tareas personalizadas.
  3. Visor de propiedades
    El clásico y popular editor de propiedades, siempre útil para editar y configurar cada una de las actividades del proceso.

 

Si miramos un poco más el detalle de ejecución de un proyecto de Build, expandiendo las actividades que lo comprenden, podremos ver que los pasos que sigue son similares que en la versión actual (hasta donde recuerdo, la definición de los Targets se respeta en 2010)

La siguiente imagen, muestra como una vez ejecutada la actividad que crea el Label correspondiente al Build, se compila el código de todos los proyectos, se obtienen los tests de impacto y se ejecutan esos tests. Expandiendo cada una de las actividades podemos ver el detalle de las mismas, o dicho de otra forma, las actividades inferiores que las componen.

e

 

Seleccionando una Actividad podemos ver las propiedades de la misma. Junto con el set de propiedades que corresponden a las actividades “hijas”. La siguiente imagen muestra las propiedades de la actividad Get Impacted Tests.

 

 

En los próximos días, postearé el paso a paso de la configuración de un Build para ser utilizado en un proceso de Gated CheckIn. Pero todos aquellos que sufran con la configuración de un Build, seguramente tendrán una sonrisa en su rostro y estarán preguntándose cuando podrán migrar a Visual Studio Team System 2010.

 

Saludos @ Here

El Bruno

Crossposting from ElBruno.com

Buenas,

una de las grandes novedades incorporadas en Microsoft Visual Studio 2008 estaba relacionada con la capacidad para configurar la ejecución de los builds. Si bien mucha gente se quedó con la idea de que era más fácil implementar Continuous Integration, una de las mejores características era que además era posibler definir políticas de retención de información para los builds. De esta forma, podíamos definir la cantidad de builds que queríamos mantener de acuerdo al estado de finalización de los mismos.

En Visual Studio Team System 2010 se extiende este concepto, incorporando además 2 novedades:

  • Capacidad para diferenciar entre Builds privados y lanzamos manualmente o por un Trigger
  • Capacidad para definir que elementos se quieren eliminar de un build

 

Ejemplos

Los siguientes ítems describen algunas de estas características:

1. Diferenciación de políticas para los builds lanzamos en modo privado y aquellos lanzamos manualmente o por un Trigger

 

2. Capacidad para definir la cantidad de resultados de Builds que se quieren mantener.

Se pueden elegir varias opciones por defecto, o definir el número como otra opción

 

3. Capacidad para definir que elementos se eliminarán en los builds.

Se pueden elegir varias opciones por defecto, o definir manualmente si se quiere retener:

  • Detalles del Build
  • El contenido de la carpeta de destino (Drop Folder)
  • Resultado de los Tests
  • Label, es posible eliminar el label que se genera automáticamente con la compilación

 

 

Saludos @ Home

El Bruno

Crossposting from ElBruno.com

Buenas,

el formulario de configuración de ejecución de pruebas unitarias de Visual Studio Team System 2010 ha cambiado bastante ya que con alguna de las novedades incluidas en esta versión el mismo ha tenido que ser rediseñado. Entre estas novedades podemos mencionar que ahora es posible almacenar junto con el resultado de las pruebas unitarias, información de contexto como las propiedades del sistema operativo, una secuencia de imágenes o un video con el paso a paso de las pruebas, etc.

En este caso quiero hablar un poco de la configuración para la cobertura de código. Como se puede ver en la siguiente imagen, lo primero que llama la atención es que desaparecen los archivos .testrunconfig y en la nueva version su extensión es .testsettings

 

El nuevo formulario de configuración de ejecución de pruebas posee varias secciones nuevas, donde es posible configurar las opciones generales, parámetros de ejecución como por ejemplo la recolección de datos de sistema, opciones de filtrado sobre estos datos, configuración de scripts pre y post ejecución, etc.

 

En las opciones de ejecución, podemos ver que ahora es posible habilitar varios sistemas de recolección de datos:

  • Profiler para ASP.NET
  • Code Coverage (cobertura de código)
  • Event Log
  • System Information
  • Video Recorder
  • Test Impact Local Collector
  • Diagnostics Trace Collector

 

La configuración de Code Coverage, permite seleccionar los assemblies que queremos analizar (aunque todavía no está disponible la opción que poseemos en VS2008 de seleccionar archivos que cumplan con un patrón al estilo *test.dll)

 

Finalmente, la ventana que muestra los resultados de la cobertura de código no ha sufrido cambios todavía, como podemos ver en la siguiente imagen donde se muestra una comparación entre 2 ejecuciones de pruebas sobre un mismo proyecto

 

Saludos @ Home

El Bruno

Crossposting from ElBruno.com

Buenas,

si alguna vez has tenido que analizar en detalle el resultado de un Build en Visual Studio, seguramente después de un par de intentos has decidido dejar de utilizar el formulario por defecto que viene en Microsoft Visual Studio 2008 y has recurrido al log; que consiste un simple archivo de texto plano, al que conviene encarar con un cafe ya que puede ser bastante tedioso de analizar.

En Visual Studio Team System 2010 el formulario de visualización de ejecución de Builds ha mejorado mucho. Ahora es posible analizar la mayoría de la información sin tener que salir del mismo y además poder realizar acciones básicas como acceder al directorio de Drop del Build, cambiar el modo del mismo para retener su información indefinidamente etc.

Se ha incluido además una vista basada en WPF del archivo plano de texto, que incorpora un navegador gráfico a la izquierda del mismo, para ayudarnos a conocer qué seccion del archivo de log estamos visualizando.

Las siguientes imágenes muestran un par de ejemplos de estas mejoras:

Ejemplos

- Cómo acceder al archivo de Log, al Drop Folder, y cambiar el estado de retención de lainformación y archivos generados por el Build.

 

- Cómo cambiar la propiedad Quality del Build

 

- Al igual que la versión anterior existe la capacidad de colapsar los grupos principales de información: Latest Activity; Summary; Associated Changesets; Associated WorkItems

 

- Informacíón gráfica con accesos directos dentro del resumen de la ejecución del Build.

 

- Vista del Log con la barra de navegación a la izquierda.

 

- El visor de Log, también incluye un formato enriquecido para la visualización de warnings y errores.

 

- Finalmente, una de las novedades más interesantes es poder ver gráficamente el resultado de la ejecución de los builds anteriores. Para esto podemos navegar en un pequeño control dentro del visor por los resultados de los builds anteriores (ojo, esto funciona un poco mal en esta CTP). La siguiente imagen muestra como podemos acceder a la ejecución de un build anterior.

 

Saludos @ Here

El Bruno

Crossposting from ElBruno.com

Buenas,

como ya he hablado un poco sobre varias novedades de Visual Studio Team System 2010, creo que es momento de recopilar las mismas en un pequeño listado (que nuestros amigos de habla inglesa seguramente titularían “What’s new in Visual Studio Team System 2010”)

WorkItems

Source Control

TFS Build

Herramientas de Modelado

Visual Studio

Varios

 

Como todavía queda mucho material por comentar y muchos posts por crear, actualizaré este listado periódicamente.

 

Saludos @ Home

El Bruno

Crossposting from ElBruno.com

BcnDev: ¡¡Conquista el mundo con Lego Mindstorms y Microsoft Robotics Studio!!Buenas,

un poco tarde pero aqui está la presentación y el código fuente del evento de la semana anterior en Barcelona donde regalamos un LEGO Mindstorms junto a los compañeros de BCNDev.Net.

 

A continuación dejo un par de fotos del evento, aunque lamentablemente salgo en algunas, asi que pueden hacer click en las otras

- Presentando el LEGO con Robotics

   

- Atacando a la asistencia con el Bot

 

 

- Entregrando el LEGO al flamante ganador del sorteo

 

 

Podeis ver todas las fotos en –> 2008 11 14 MSRobotics en Barcelona

 

Saludos @ Here

El Bruno

Crossposting from ElBruno.com

Buenas,

el formulario de histórico de ejecución de Builds ha cambiado muy poco en Visual Studio Team System 2010; sin embargo en el listado de Builds se incorpora una columna que es fundamental para poder averiguar de un vistazo quien ha lanzado el Build “Requested By”.

 

Además de esta nueva columna, podemos encontrar además un CheckBox para filtrar por los Builds lanzados por el usuario y algo que ya comenté hace 2 días, la posibilidad de actualizar el repositorio de código fuente con el contenido de un ShelveSet.

 

En este mismo momento, estoy pensando en sugerir que en lugar del CheckBox para el filtrado del usuario logueado, se podría implementar un combo con el listado de usuarios que tienen permisos de build y filtrar por los mismos.

 

Saludos @ Here

El Bruno

Crossposting from ElBruno.com

Buenas,

ayer comenté un poco sobre los nuevos "Gated CheckIn" incluidos en Visual Studio Team System 2010. Una de las grandes ventajas de esta nueva funcionalidad radica en que es posible validar secciones de código específicas utilizando un proceso de Build (con todo lo que conlleva, compilación, ejecución de pruebas, etc.) antes de que las mismas suban al gestor de código fuente en un ChangeSet.

Para poder trabajar de esta forma, estas compilaciones aprovechan la capacidad de crear estadios intermedios para nuestros archivos a través de ShelveSets (recomendado leer este link para comprender como funcionan).

Los siguientes apartados detallan algunos puntos a tener en cuenta:

1. En la sección de Triggers de un Build podemos definir que el mismo se dispare manualmente para trabajar con ShelveSets

 

2. Cuando se desea encolar una nueva Build, podemos ver que en la misma existe una opción "What do you want to Build?" que permite seleccionar entre el código fuente del servidor TFS o un ShelveSet en particular. En el caso del ShelveSet, tenemos un formulario para poder seleccionar el mismo de la lista de ShelveSets existentes en el Server.

Asimismo es posible, definir que si la compilación no tiene errores, los cambios del ShelveSet se suban como un ChangeSet con la opción "Check in changes after successful build"

 

3. El listado histórico de Builds y en ejecución, permite distinguir los 2 tipos de Builds, con una imagen especial. En la siguiente imagen, los Builds 2, 3, 4 y 5 han sido lanzados desde un ShelveSet

 

4. Finalmente en un Build ejecutado sin errores, si no se ha seleccionado la opción de subir los cambios automáticamente; es posible subir los cambios de código del ShelveSet a nuestro servidor de código fuente como un ChangeSet

 

Saludos @ Home

El Bruno

Referencias:

Crossposting from ElBruno.com

Buenas,

hace unos días Enrique propuso un par de escenarios comunes de trabajo donde se planteaba la posibilidad de realizar una validación previa al CheckIn de un desarrollador utilizando un Build, para validar de esta manera la calidad y el trabajo del código a subir al control de código fuente. En el post, se nombraron varias herramientas y yo dejé caer como posibilidad comenzar a estudiar una nueva característica incluida en Visual Studio Team System 2010 denominada Gated CheckIn (he realizado una pequeña búsqueda y me parece que no hay referencias a este término fuera del mundo MS).

La principal base de esta funcionalidad se basa en que los desarrolladores no pueden subir código directamente en el control de código fuente. En cambio, se sube un ShelveSet con los cambios pendientes y se realiza una Build con el mismo para comprobar la compilación y si se pasan las pruebas unitarias. Si toda la acción ha ido correctamente, se procede al CheckIn.

 

Descripción Paso a Paso

1. Una parte importante de este proceso es configurar un Build dentro de un Team Project en Team Foundation Server 2010, donde el trigger que dispare el mismo, sea un Gated CheckIn. La siguiente imagen muestra la nueva ventana de propiedades para los triggers de un Build

 

2. Luego de configurar este Build en un Team Project, al momento de realizar una tarea de CheckIn, podremos ver que además de los pasos usuales del proceso, aparece una nueva ventana alertando que los cambios deben ser validados previos al CheckIn. Esta opción creará un nuevo ShelveSet, y he optado como opción preservar los cambios localmente

 

3. Un nuevo Build se agrega en el servidor de compilación y el resultado del mismo, definirá si los cambios en el código se suben al control de código fuente.

 

4. En este caso en particular he incluido errores en el código para que el Build sea erróneo, con lo que los cambios no se aplicarán.

 

5. Una vez solucionados los problemas en el código fuente, y verificadas las pruebas correspondientes; un nuevo proceso de CheckIn es disparado. Sin embargo en este caso, el resultado del mismo es correcto lo que nos habilitará a subir los cambios al control de código fuente.

 

6. Para subir estos cambios, debemos seleccionar el Build correcto, y desplegando el menú contextual sobre el mismo seleccionar la opción "Update Workspace". 

 

7. Esto nos permitirá "reconciliar" los archivos del Build, basados en un ShelveSet, con los archivos del Source Control para de esta forma, poseer una versión definitiva y correcta de los mismos.

 

8. CheckIn listo y con las pruebas completas !!!

 

Los Gated CheckIn son una de las grandes novedades en la nueva versión de Visual Studio Team System 2010, sin embargo creo que todavía se puede mejorar mucho la integración y experiencia de usuario con los mismos, por ejemplo añadiendo un par de opción para un Build por defecto en un Team Project, o mejorando la ventana de CheckIn.

Como todavía falta para la versión final de VSTS 2010, seguro que nos encontraremos con un par de novedades por el camino.

 

Saludos @ Home (finally)

El Bruno

Crossposting from ElBruno.com

Buenas,

si bien todo el mundo sabe que es altamente recomendable ejecutar las pruebas definidas antes de subir el código fuente al gestor de código muchas veces por vagancia o por desgano esta tarea no se realiza. En muchas ocasiones, el argumento suele ser que la ejecución de todos los tests "tarda mucho" y esto ralentiza la dinámica del equipo de trabajo (recordemos que cuando más rápido mejor).

Por suerte Visual Studio Team System 2010 incorpora un nuevo panel que puede ayudarnos bastante "Test Impact View". Este panel, como muestra la siguiente imagen nos proporciona una vista de todas las funciones que hemos modificado y además la lista de Tests que afectan a cada una.

 

 

Para poder identificar los tests que afectan al código modificado, esta ventana se vale de una definición de un Build donde se especifica uno o más proyectos a compilar, con sus correspondientes tests. Una vez identificados, simplemente podremos ejecutarlos y asegurarnos que, antes de hacer CheckIn, como mínimo hemos probado con los tests definidos para el código que hemos modificado.

Nota: para que la funcionalidad de mostrar los tests funcione correctamente, la opción de Code Coverage debe estar habilitada; en caso contrario no funcionará.

 

Saludos @ AVE (Bcn->Madrid)

El Bruno

Crossposting from ElBruno.com

Buenas,

el nuevo formulario para presentar la información histórica de un elemento del Source Control Explorer incorpora nuevas funcionalidades que se echaban en falta desde hace tiempo. Especialmente si trabajas con Branches y con un esquema de promoción de información entre los mismos.

Por ejemplo, en la siguiente imagen podemos ver que en el listado histórico de los ChangeSets del archivo Customer.cs, vemos no solo el histórico de ChangeSets, sino que además podemos ver la relación que tiene con otros cambios de otros Branches de forma jerárquica.

 

Además podemos:

  • Ver el contenido del archivo en el momento del ChangeSet
  • Ver el detalle del ChangeSet
  • Comparar archivos entre 2 ChangeSets de la lista
  • Comparar directorios entre 2 ChangeSets de la lista (so cool !!!)
  • Ver el detalle en modo Annotate del archivo en el ChangeSet (Historic Annotate)
  • Obtener el archivo de esa versión
  • Realizar un seguimiento de cambios

Sobre este último punto quiero detallar un poco más, ya que esta funcionalidad es una de las más importantes según mi punto de vista. Pensemos durante un segundo que tenemos un escenario complejo con muchos Branches; en este tipo de escenarios poder realizar un seguimiento de los cambios a los distintos Branches suele ser una tarea compleja. Sin embargo, la siguiente herramienta nos puede ayudar bastante.

Al momento de seleccionar la opción "Track Changeset", veremos un formulario para definir el scope (los Branches) de la búsqueda de información.

 

A continuación, podremos ver en otro DSL en otro formulario visual, en que fechas se han ido pasando los cambios del ChangeSet original a los diferentes Branches.

 

Además, sobre cualquiera de los ChangeSets que aparecen en el visor, podremos realizar las acciones básicas de trabajo sobre un ChangeSet, incluido el drag and drop de diferentes ChangeSets entre diferentes Branches

 

Finalmente no quiero dejar de mencionar que a todas estas acciones que realizamos sobre uno o más ChangeSets, también las podemos realizar sobre un listado histórico de Labels, utilizando la 2da pestaña del formulario de histórico de un archivo.

 

Saludos @ Barcelona

El Bruno

Crossposting from ElBruno.com

Buenas,

y casi me olvido !!! la próxima semana tenemos un día de contenidos geniales por un lado tenemos al gran David Salgado comentándonos algunas de las novedades que se vieron hace un par de semanas en el PDC. Si te interesa conocer alguna de estas novedades: Windows on the cloud, Microsoft Azure, Internet Explorer 8, VSTS 2010, .Net Framework 4.0, Dublin, Oslo, Windows 7, DSS / CCR, etc.; seguramente esta es una buena oportunidad para tener una charla cara a cara con David.

Y por otra parte comentaros que somos parte del VB & VS Spanish TOUR

Serán eventos eminentemente técnicos, impartidos en Inglés, divididos en dos sesiones y de un total de 3 horas. En cada sesión intentaremos abordar lo más relevante del IDE de Visual Studio desde su versión 2005 sin obviar lo que ya se está preparando para la versión del 2010. Los “Speakers” serán Lisa Feigenbaum, Program Manager del Editor de Visual Basic y Jonathan Aneja, Program Manager en el equipo de VB en Redmond.

VB/VS Spanish Tour - Madrid

09:15 - Recepcion

09:30 - Bienvenida

09:45 - VB 2005, VB 2008 and VB 2010 IDE
            XML Literals

11:00 - Cofee Break
11:15 - VB 2010 Language features
            LINQ to ADO/SQL & Objects
            Interop Toolkit & PowerPacks

12:30 - Q & A

Registro: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032395845&Culture=es-ES

 

MAD.NUG: PDC Highlights

El PDC es un evento internacional de Microsoft donde se presenta el futuro de muchos productos, herramientas y frameworks.
En esta sesión intentaremos dar un repaso a los anuncios más relevantes para el colectivo de desarrolladores.

Ponente: David Salgado (Development Evangelist. Microsoft Ibérica)

Registro: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032396287&Culture=es-ES

Disclaimer: obviamente en los 90 minutos de David no se pueden cubrir todos los temas del PDC, pero seguro veremos algo interesante !!! y con respecto al primer evento -> Genial !!!

 

Saludos @ TechEd

El Bruno

Crossposting from ElBruno.com
Publicado 13/11/2008 14:16 por El Bruno | con no comments
Archivado en:

Buenas,

si te has bajado la CTP de Visual Studio Team System 2010 y de .Net Framework 4.0; seguramente ya has tenido mucho tiempo para conocer alguna de las novedades que se incluyen en esta versión.

Si quieres conocer un poco más no puedes dejar de bajar el Training Kit para esta versión:

Visual Studio 2010 and .NET Framework 4.0 Training Kit - November Preview
http://www.microsoft.com/downloads/details.aspx?FamilyId=752CB725-969B-4732-A383-ED5740F02E93&displaylang=en

Dentro del mismo se encuentra el siguiente material:

Presentations

  • Overview of the .NET Framework 4.0
    This presentation goes over the new technologies and enhancements being made in the version 4 release of the .NET Framework.
  • Overview of the Visual Studio 2010
    This presentation covers is a high-level over of the value propositions for Visual Studio 2010 and a walkthrough some of the great features being added to the IDE.

Hands-on-Labs

  • Visual Studio 2010: Office Programmability
    In this lab you will see how new features in Visual Studio 2010, C# 4.0, and Visual Basic 10 make it easer to develop applications leveraging Microsoft Office. Additionally, you'll see a number of other powerful features which speed other elements of Office development.
  • Visual Studio 2010: Test Driven Development
    Visual Studio 2010 brings with it several enhancements to help cut development friction and enable the developer to focus on the task at hand: writing high-quality code. In the following exercises we'll highlight several of the new features that the TDD developer can use to enhance his/her development cadence. Visual Studio helps your cadence by cutting the number of keystrokes to accomplish frequently performed tasks, speeds navigation through your solution, and enables you to use test frameworks other than MSTest.
  • Parallel Extensions: Building Multicore Applications with .NET
    Microsoft's Parallel Computing Platform (PCP) is providing tools enabling developers to leverage the power of Multicore processors in an efficient, maintainable, and scalable manner. Parallel Extensions to the .NET Framework brings several important concepts into this toolset. In this Hands-On Lab, you will learn how to parallelize an existing algorithm by using the static Parallel helper class, create and run Tasks, use the Future<T> class to create and run Tasks that return a value and use Parallel LINQ (PLINQ) to optimize LINQ queries to exectue in a parallel environment
  • Introduction To Managed Extensibility Framework (MEF)
    The Managed Extensibility Framework (MEF) allows developers to provide hooks into their .NET applications for extensions by first and third parties. MEF can be thought of as a general application extension facility. In this Hands-On Lab, you will learn how to define extensibility points for components, perform conditional binding and component creation and import extended assemblies while an application is running.
  • ASP.NET AJAX
    In this Hands-On Lab, you will learn how to leverage new client-side templates to easily bind data to your UI, use the DataView control to render data on the client, extend the template engine by creating custom Markup Extensions, and declaratively instantiate behaviors and controls
  • ASP.NET Dynamic Data
    ASP.NET Dynamic Data MVC allows developers to create web based applications that dynamically create pages based on the application's data model. ASP.NET Dynamic Data MVC provides scaffolding and templates that are easily customizable and extensible to reflect the custom functionality required for a solution. In this Hands-On Lab, you will learn how to use Dynamic Data MVC to easily render data over forms and then to easily create your own views and enforce data validation.
  • Intro To Project "Velocity"
    In this Hands-On Lab, you will learn how to install and configure Velocity, program against Velocity's API and use Velocity's SessionState provider with ASP.NET.
  • Intro To F#
    This Hands-On Lab is comprised by the following exercises. Examine the basic F# types including tuples and functions. Discover how the "let" keyword allows values to be bound to identifiers. See that in F# funcations are the same as any other value, and are handled the same way. Demonstrate how this allows advanced langage features such as parially-applied or "curried" functions. Discover how F# lists are built and the power that can be achieved by F#'s "Head + Tail" approach. Demonstrate the powerful pattern matching and recusion capabilities of F#. Demonstrate the power and usefulness of discriminated unions in F#.

 

Materiales:

 

Saludos @ TechEd

El Bruno

Crossposting from ElBruno.com
Más artículos Página siguiente >