Mostrando entradas con la etiqueta TFS. Mostrar todas las entradas
Mostrando entradas con la etiqueta TFS. Mostrar todas las entradas

martes, 25 de septiembre de 2012

Cómo hacer funcionar un servidor de compilación de TFS 2010

Sin morir en el intento

Situación inicial

Pongamos que tenemos una instalación nueva, limpia, de un sistema TFS 2010, con su servidor de Base de Datos, su servidor de TFS 2010, y ahora queremos instalar una máquina para las compilaciones.

Sin problemas ¿no? instalamos la parte del servicio de Builds desde el DVD de TFS 2010 y listo (bueno, listo no, primero lo tenemos que enganchar al servidor de TFS, pero hasta aquí es tal y como pone en toda la documentación de Microsoft)

El problema

Una vez instalado y configurado, generamos una nueva definición de Build, así como lo hemos hecho siempre, sin nada especial, y la lanzamos. El resultado:

image

Otro que nos puede también aparecer (este relacionado con la compilación en 32 ó 64 bits):

image

Y por supuesto alguno más, como el mensaje del “Tracker.exe” del que ya hablé aquí.

[modo enfado ON]

Puedo entender que cuando montamos un sistema de compilación existan determinados tipos de proyectos que de partida no podamos compilar sin alguna configuración ‘especial’ (por ejemplo los de Sharepoint) o que si el proyecto utiliza componentes de terceros haya que realizar alguna operación especial, pero ¿cómo es posible que no sea capaz de compilar un mini proyecto de prueba sin nada especial?

O por lo menos, en la documentación que lo avisen: “Instalar únicamente el servidor de Compilaciones NO permite compilar proyectos”.

[modo enfado OFF]

En fin, es lo que hay. ¿cómo lo solucionamos?

La solución

El mensaje de error de la compilación nos da varias opciones para solucionar el problema (en este caso el del “resgen.exe”)

  1. Install the Microsoft Windows SDK. 
  2. Install Visual Studio 2010. 
  3. Manually set the above registry key to the correct location. 
  4. Pass the correct location into the "ToolPath" parameter of the task.

Vamos a ver, si es obligatorio tener instalado algún SDK o el Visual Studio, ¿por qué no lo dicen en ningún sitio? Que no lo digo por no instalar, lo digo por la cara de tonto que se te queda…

En mi caso, lo que mejor me venía era instalar el SDK de Windows, en concreto “Microsoft Windows SDK for Windows 7 and .NET Framework 4

Una vez instalado, ya compila correctamente.

Nota mental

Es muy posible que al intentar compilar un proyecto web aparezca el siguiente mensaje:

image

Esto es porque no hemos instalado el Visual Studio 2010, para solucionarlo sin necesidad de instalar este producto, basta con instalar el Team Explorer en el servidor de Compilación.

De hecho, en muchas páginas que he consultado para estos problemas recomiendan instalar Visual Studio en la máquina de compilación, que además no consume licencia… Igual es lo más fácil.

martes, 3 de julio de 2012

Ensamblados comerciales y builds de TFS

O cómo modificar las builds para TFS 2010.

Cuando estamos desarrollando una aplicación, es frecuente que necesitemos o decidamos utilizar algún componente comercial para simplificar el propio desarrollo o para mejorar la experiencia del usuario.

En este artículo vamos a revisar y solucionar un problema muy común que aparece cuando queremos realizar compilaciones automáticas de estos proyectos mediante Team Foundation Server 2010.

El problema

Pongamos que en mi aplicación estoy utilizando un control de menú muy ‘mono’, que me pinta las barras de herramientas como si de la Ribbon de Office se tratara.

Pongamos también que ese control de menú es comprado y licenciado, en la clásica licencia de componentes para .NET que requiere una licencia para cada desarrollador pero no requiere licencias de ejecución (ojo que este punto es importante, este artículo sólo aplica en estos casos)

Termino mi jornada y hago un check-in del formulario que desencadena una compilación en el servidor de Builds.

¡Sorpresa!

image

La causa

Si observamos la captura anterior, podemos ver que el error al compilar se está generando con el archivo “licenses.licx”

¿Pero qué es este archivo?

En las condiciones que hemos especificado en el punto anterior, en este archivo aparecen los componentes de terceros que estemos utilizando en nuestro proyecto y que además requieran de un control de licenciamiento en la máquina de desarrollo. El contenido concreto, que no voy a reproducir aquí, es una serie de líneas de texto ‘plano’ que indican la ‘firma’ de los componentes que requieren licenciamiento.

El problema que está encontrando el servidor de Builds es que al lanzar la compilación está realizando las operaciones necesarias para comprobar la licencia de todos los controles que aparezcan en este archivo.

Una posible solución

Revisando este problema por Internet, una de las propuestas que he encontrado es quitar ese archivo del control de versiones, con lo que al lanzar la compilación el archivo no existirá y en consecuencia el servidor no intentará validar las licencias. Reconozco que esta opción no la he probado, porque excluir un archivo del proyecto del control de versiones me da la sensación de que me puede acabar generando problemas a posteriori.

La solución

Como la primera alternativa no me convence, es hora de probar otra cosa. He leído por ahí que si el archivo está vacío, hará el mismo efecto que si está fuera del control de fuentes. Esto por si sólo tampoco es que sea una mejora de lo anterior, ya que tendríamos que vaciar el archivo ‘a mano’ antes de cada Build (inaceptable)

Lo que vamos a hacer a cambio, es generar una tarea personalizada para el flujo de compilación que cuando se ejecute limpiará el contenido del archivo automáticamente. De esta forma, las copias de trabajo y el control de fuente no corren riesgo de quedar en un estado inestable, y a su vez el proceso de compilación funcionará correctamente.

Al turrón

Vamos a trabajar con Visual Studio 2010.

Creación del proyecto

  1. Creamos una solución con dos proyectos de “Class Library”. Uno de los proyectos contendrá las tareas personalizadas (CustomBuildActivities) utilizando .Net 4 y el otro contendrá la plantilla de proceso que vamos a modificar para incluir nuestra tarea (CustomBuildProcess).
  2. Localizamos la plantilla de proceso por defecto “DefaultTemplate.xaml” y cambiándole el nombre la incluimos en el proyecto CustomBuildProcess. Una vez incluida, tenemos que modificar su propiedad “Build Action” a “XamlAppDef”.

    image

Creando una actividad personalizada

Para que este sistema funcione, necesitaremos una actividad que nos permita manipular el atributo de sólo lectura de nuestro archivo, ya que si está marcado como de sólo lectura, difícilmente podremos manipular su contenido.

En nuestro proyecto CustomBuildActivities añadimos un nuevo elemento de tipo “Workflow”, “Code Activity”, en este caso voy a utilizar el nombre “SetReadOnlyFlag”. El código de esta clase está disponible en el archivo adjunto y sus características más relevantes son las propiedades que definimos para controlar el Workspace donde el servidor de compilación almacena los archivos y los archivos a manipular.

Necesitamos también una actividad que nos permita modificar el contenido del archivo. Para esta actividad voy a utilizar el nombre “UpdateLicensesContent”. El código de esta clase está disponible también en el archivo adjunto y sus características más relevantes son las propiedades de definimos para localizar el archivo a manipular. Básicamente lo que hace esta actividad es localizar el archivo y, si no está vacío, vaciarlo.

Actualizando el flujo de trabajo de compilación

Hasta ahora hemos preparado unas actividades que nos permitirán manipular el archivo de licencias, pero ahora llega el momento de utilizarlas.

Para ello abrimos el proceso de Build en el proyecto “CustomBuildProcess”. En la caja de herramientas veremos las actividades que hemos programado anteriormente:

image

Lo que vamos a hacer va a ser ubicar nuestras tareas en el punto adecuado del flujo, para ello en el flujo localizamos la siguiente sección:

image

Justo después de “Get Workspace” añadimos una actividad de tipo “Sequence”, le cambiamos el nombre de manera adecuada y añadimos dentro la actividad personalizada que hemos creado “SetReadOnlyFlag”.

image

Los indicadores de error significan que nos falta informar las propiedades de la actividad, para ello vamos al panel de propiedades:

image

Lo que vamos a hacer es permitir a los usuarios especificar los valores de la propiedad “FileMask” en la ventana de definición de la Build, para darle más flexibilidad al sistema y además los valores de la propiedad “Workspace” estarán basados en la propia Build actual.

Para permitir a los usuarios interactuar con la propiedad “FileMask”, añadimos un nuevo “Argument” al Flujo que estamos personalizando, utilizando para ello el botón “Arguments” que aparece en la parte inferior del diseñador del Flujo. Una vez que se abre el panel de argumentos, vamos al final del mismo y hacemos clic en “Create Argument”, creando nuestro argumento (en este caso “LicensesMask”) e indicando el valor deseado:

image

Antes de utilizar este argumento en nuestra actividad, tenemos que habilitar su ‘presencia’ en la ventana de definición de la Build. Para esto en el panel de argumentos localizamos “Metadata” y añadimos un parámetro a la colección:

image

Una vez añadido el parámetro, actualizamos la propiedad “FileMask” en la actividad “SetReadOnlyFlag” para utilizar el argumento que acabamos de crear, así como el resto de propiedades:

image

Una vez configurada la actividad, añadimos a continuación la segunda actividad personalizada “UpdateLicensesContent” y otra instancia de la actividad “SetReadOnlyFlag” y establecemos sus correspondientes propiedades:

Actividad “UpdateLicensesContent”

image

Segunda actividad “SetReadOnlyFlag”

image

y ya está todo preparado para utilizar el nuevo proceso de Build.

Utilizar el nuevo proceso de Build

Para poder utilizar el proceso de Build, tenemos que asegurarnos de que tanto el propio proceso como las actividades personalizadas están disponibles para el sistema. Para ello lo más común es añadir la plantilla de proceso a la carpeta “BuildProcessTemplates” y las actividades en una subcarpeta, por ejemplo “CustomActivities”. Esta carpeta está accesible desde el Team Explorer:

image

Lo siguiente que tenemos que hacer es indicar al controlador de compilaciones dónde tiene que ir a buscar las actividades personalizadas, para ello en el elemento “Builds”, hacemos clic con el botón derecho del ratón y elegimos “Manage Build Controllers”

image

En la ventana que se abre especificamos la ruta a las actividades personalizadas:

image

Ahora ya podemos generar una nueva compilación que utilice nuestra plantilla de proceso.

Lo único que tenemos que tener en cuenta al generar la nueva definición de build es que en la pestaña “Process” tendremos que elegir nuestra plantilla personalizada en lugar de la que propone Visual Studio por defecto:

image

El resultado

Una configurado el nuevo proceso de compilación, el resultado del mismo ya, por fin, es el esperado:

image

El código asociado a este artículo estará disponible próximamente como adjunto y en Codeplex, en cuanto lo tenga publicado actualizaré esta entrada. Si alguien quiere más información no tiene más que dejar un comentario.

viernes, 23 de marzo de 2012

TFS Builds, error con “Tracker.exe”

Una rápida para terminar la semana…

Situación inicial

Tras instalar un nuevo servidor de compilación, la primera Build configurada para un proyecto de tipo Windows Forms, falla con el siguiente mensaje:

image

 

Posibles soluciones

Como indica el propio mensaje, hay varias soluciones posibles:

  1. Instalar el Windows SDK v7.0A o superior.
  2. Instalar Visual Studio 2010.
  3. Establecer ‘a mano’ una propiedad en el registro de Windows.
  4. Desactivar la operación que desencadena el error en la compilación.

La primera opción entiendo que es la mejor y la que aplicaré en el servidor de compilación, pero no quería tener que hacerlo hoy.

Las segunda y tercera opciones, pues cómo decirlo, no me convencen. No quiero tener que instalar Visual Studio 2010 en un servidor de CI, y por supuesto que NO quiero tampoco andar jugueteando con el registro (si no es estrictamente necesario)

La cuarta opción es la que he aplicado de manera temporal y la verdad es que funciona perfectamente.

Desactivar la generación de recursos incremental

En el mensaje lo pone muy fácil:

You can turn off incremental resource generation by setting the "TrackFileAccess" property to "false"

Investigando por Internet, he visto que es un parámetro que se le puede indicar al “MSBUILD”, e incluso que se puede añadir en la definición XML de la compilación.

Lo que no tenía tan claro era cómo aplicar ese parámetro a la definición de la compilación desde el propio Visual Studio, y al final ha sido sencillo, basta con introducir el parámetro en la definición de la compilación, como aparece en la siguiente captura:

image

Ojo porque hay que añadir la marca de parámetro, quedando así:

/p:TrackFileAccess=false

Una nota curiosa, otras compilaciones configuradas en el servidor funcionaban correctamente, pero ninguna utilizaba archivos de recursos…

Y ya está solucionado, ahora que no se me olvide instalar el dichoso SDK.

miércoles, 8 de febrero de 2012

Cómo conectar Visual Studio 2008 con TFS 2010

Este es un mini post con las instrucciones básicas para conseguir conectar Visual Studio 2008 con proyectos en Team Foundation Server 2010.

Al turrón

  1. Instalar el Service Pack 1 de Visual Studio 2008
  2. Instalar la actualización para TFS 2010 (Visual Studio 2008 SP1 Compatibility Update for TFS 2010)
  3. Instalar el Team Explorer (Visual Studio Team System 2008 Team Explorer)

Estos tres primeros pasos son ‘opcionales’ lógicamente si ya tenemos instalado el Service Pack 1, el paso 1 nos lo podremos saltar, así como la instalación del Team Explorer si ya lo tenemos o si la versión de Visual Studio 2008 es la “Team Suite”

Lo último que hay que hacer es añadir manualmente el servidor de TFS. Para esto, en el registro de Windows tendremos que añadir la entrada correspondiente a dicho servidor. ¿Dónde?

  1. Navegamos a la entrada “[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers]”
  2. Creamos un nuevo Valor de Cadena y en el nombre ponemos el nombre del servidor, y en el valor ponemos la url de acceso al TFS, como podemos ver en la captura posterior.
  3. Creamos una nueva Clave con el nombre del servidor utilizado en el paso 2.
  4. En la nueva Clave, creamos dos valores DWORD con las características de la tabla que aparece más abajo

Y ya estamos listos para conectar desde Visual Studio al servidor TFS, abriendo la ventana del Team Explorer y seleccionando el servidor entre la lista de disponibles.

Más información:

Registro del servidor TFS (Paso 2)

image

Datos de configuración del servidor (Paso 4)

Nombre Valor
AutoReconnect 1
Offline 0

 

Si tenemos que hacer esta configuración en varios equipos, es conveniente generar un archivo .reg para automatizar la modificación del registro, este sería el contenido con los datos que hemos utilizado:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers]
"
ServidorTFS"="http://servidorTFS:8080/tfs/ProjectCollection"

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\TeamFoundation\Servers\ServidorTFS]
"Offline"=dword:00000000
"AutoReconnect"=dword:00000001

Selección del servidor en Team Explorer:

image

jueves, 12 de enero de 2012

Generar builds en TFS para proyectos de Sharepoint

O cómo compilarlos automáticamente sin morir en el intento.

Los últimos días he retomado el desarrollo de componentes para Sharepoint, que tenía bastante “oxidado” y como no podía ser de otra manera, he integrado el proceso de desarrollo dentro del TFS 2010. La situación que tenía (para tener claro de qué estoy hablando) era la siguiente:

  • Equipo de desarrollo: Windows 2008 R2 de 64 Bits.
  • Sharepoint Server 2010 instalado en el equipo de desarrollo.
  • Visual Studio 2010.
  • Servidor de fuentes: Team Foundation Server 2010.

 

Pasos Previos

Lógicamente antes de nada, hay que realizar las operaciones clásicas cuando utilizamos TFS (creación del Team Project, rama Main, etc.)

Hasta aquí nada nuevo bajo el sol, estuve realizando el componente (en este caso una WebPart) y llegó la hora de probarlo en el entorno de Preproducción.

Para la instalación en ese entorno, únicamente utilicé el WSP que genera Visual Studio al ‘empaquetar’ el proyecto de Sharepoint, pero se me ocurrió que tenía que ser posible utilizar las Builds de TFS para que ese paquete WSP se genere automáticamente, como el resto de productos alojados en TFS.

La verdad es que no resultó tan sencillo como yo esperaba, aunque los problemas y pasos para solucionarlos tienen mucho sentido.

Primer intento

Lo primero que intenté fue lo típico, generé una nueva Build Definition, y la ejecuté… Resultado:

image

Como vemos, al realizar la compilación el agente detecta que en el proyecto hay referencias que no le gustan, o que no conoce, vamos, que no existen en el servidor…

Esto es normal, ya que ni Visual Studio ni, por supuesto, Sharepoint están instalados en el servidor de compilación.

Segundo intento

Como no funcionó, tocó “googlear” un rato, y lo primero que encontré fue un “apunte” en el que indicaba que con una Build Definition ”normal” no se conseguía generar el WSP para el componente. Para solucionar ese problema, es suficiente con añadir el parámetro “/p:IsPackaging=True” en la sección de “MSBuild Arguments” de la Build Definition:

image

Pero aún hay más, encontré una pequeña ‘maravilla’ que en principio simplifica el proceso. Dicha maravilla es un script de Powershell que en un primer paso permite coger los ensamblados de Sharepoint de la máquina de desarrollo, y en una segunda pasada los copia y registra en el servidor de compilación. No voy aquí a repetir los pasos de ejecución de dicho script, ya que está suficientemente explicado aquí, pero baste una captura para ver el resultado de la compilación una vez ejecutado el script tanto en la máquina de desarrollo como en el servidor de compilación:

image

Bueno, tampoco íbamos a esperar que funcionase a la primera no?

Lo que ha pasado es que el script que hemos ejecutado sólo coge los ensamblados básicos de Sharepoint:

"Microsoft.SharePoint.dll"
"Microsoft.SharePoint.Security.dll"
"Microsoft.SharePoint.WorkflowActions.dll"

Como nuestro proyecto es una Web Part que hereda de un tipo de "Microsoft.Office.Server.Search.dll", tendremos que añadir dicho ensamblado en la sección “$Script:SharePoint14ReferenceAssemblies” del script que hemos ejecutado.

NOTA: Al ejecutar el nuevo script en la máquina de desarrollo es posible que nos dé un error de que ese ensamblado no se puede localizar, si es el caso, basta con copiarlo desde la carpeta ISAPI de Sharepoint a la carpeta “Files” que se genera al ejecutar el script (si no sabes dónde está la carpeta ISAPI, creo que te has equivocado de post)

Al final, después de pruebas y error, llegamos al…

Tercer intento

En el script mágico tuve que añadir los siguientes ensamblados en la sección que indicaba antes:

"Microsoft.Office.Server.dll"
"Microsoft.Office.Server.Search.dll"
"System.Web.DataVisualization.dll"

Tras ejecutarlo en el servidor de compilación, lanzamos la Build y:

image

¡Por fin! ya tenemos compilaciones automáticas desde TFS 2010 de proyectos para Sharepoint; además, podemos observar en la carpeta de los Drops que la compilación ha generado el paquete WSP:

image

Nota final

Como podemos ver en la última captura, la Build no sólo genera el paquete WSP, sino que también está llevando a la carpeta de Drops los ensamblados que hemos añadido durante el proceso. He investigado un poquillo y parece ser que se podrían eliminar de dicha carpeta en uno de los pasos del Workflow de la Build Definition, pero reconozco que no he ahondado más en el tema. Si por lo que sea llegamos a tener problemas de espacio, podemos borrar todos esos ensamblados de las distintas compilaciones. Oye, aunque tengamos que borrarlos a mano, sigue siendo mejor que lo que teníamos antes no?

miércoles, 21 de septiembre de 2011

Utilizar TFS 2010 desde VB 6

Pequeño apunte para que no se me olvide.

Microsoft publicó hace un tiempo un proveedor / componente para permitir que productos que no soportan de forma nativa la conexión con el control de versiones de TFS puedan soportarlo.

Según la documentación de aquí,​ este proveedor permite conectar a TFS 2010 desde, entre otros, Visual Studio .NET 2003, Visual Visual Basic 6 SP6 y SQL Server Management Studio.

Mi experiencia personal ha sido con VS.NET 2003 y funciona 'de lujo' así que entiendo que con el resto de productos funcionará también perfectamente.

¡Ojo! Requiere .NET 4.0 y Team Explorer 2010 para funcionar. El proveedor está disponible para su descarga en el enlace anterior.

martes, 6 de septiembre de 2011

Los Informes de TFS 2010 no funcionan (no funcionaban)

Ayer al instalar las plantillas de Scrum para TFS 2010 de Microsoft (Visual Studio Scrum 1.0) me di cuenta de que los informes de estado de TFS no estaban funcionando. Estos informes son los que se utilizan para revisar el estado de un proyecto en TFS (Tareas finalizadas / pendientes, número de Bugs, etc)
Lo que sucedía es que cada vez que accedía a uno de los informes, el servidor de Reporting devolvía este error:
"Error al procesar el informe. (rsProcessingAborted)
Error de ejecución de consulta para el conjunto de datos 'dsBurndown'. (rsErrorExecutingCommand)
Para obtener más información acerca de este error, vaya al servidor de informes en el equipo del servidor local o habilite los errores remotos
"

Tras mucho mirar por ahí y realizar pruebas, la solución resultó ser 'medianamente' sencilla.
El problema, por lo que pude comprobar estaba en el procesamiento del cubo OLAP explotado por los informes. Por lo visto, la primera vez que se tiene que procesar el cubo no funciona directamente desde la herramienta del SQL Management Studio, sino que hay que hacerlo a mano.
¿Cómo lo hacemos a mano? TFS dispone de una serie de Servicios Web de administración que, entre otras cosas, permite precisamente eso. El servicio web en concreto es el que se llama "WarehouseControlWebService" la url de acceso es: http://servidorTFS:puerto/tfs/TeamFoundation/Administration/v3.0/WarehouseControlService.asmx
Una
vez que accedemos al Servicio, hacemos clic en la operación "ProcessAnalysi​sDatabase", establecemos el valor del parámetro "processingType" a Full (tal cual está escrito, es un parámetro de tipo string) y hacemos clic en "Invoke"
Una vez realizada esta operación, teóricamente deberíamos ser capaces de procesar el cubo de nuevo desde el Management Studio, pero no lo he probado, ya que lo que quería era que los informes funcionasen y... voilá, funcionan!
NOTA: Conviene destacar que no he realizado un estudio en profundidad del problema, por lo que no descarto que vuelva a aparecer; simplemente me ha resultado de utilidad constatar que al regenerar el cubo mediante el servicio web de TFS los informes empiezan a funcionar correctamente. ¡Ya tenemos informes de "Sprint Burndown"!