Distribuir los componentes de cliente al equipo de cada desarrollador era uno de los aspectos de Team System sobre los que Microsoft había tenido algunas quejas y han intentado mejorar en ese aspecto. Por componentes de cliente entendemos las dlls de las políticas de checkin y las dlls de los custom controls para los tipos de workitems personalizados.
Pues bien, por un lado las políticas de checkin debían estar en cada máquina y además las rutas de la ubicación de las dlls debían estar incluidas en el registro de Windows para que Visual Studio pudiese localizarlas. Otra opción es que las dlls de las políticas estén en la carpeta «<ApplicationData>MicrosoftTeam Foundation», cosa que he aprendido indagando el funcionamiento de las Power Tools, todo hay que decirlo, porque no creo que hayan añadido esa funcionalidad como parte de esta release de las Power Tools. Independientemente de eso, la realidad es que esto no ha cambiado, lo que ha cambiado ha sido la forma de distribuirlas. Antes la distribución se hacia mediante un paquete de instalación que dejase las dlls en una ubicación y que insertase una clave en el registro indicando dicha ubicación o bien podíamos realizar estos dos pasos de forma manual, el fin era que TFS reconociese esas dlls como políticas y que no diesen error cuando intentábamos hacer checkin en un proyecto.
Respecto a los custom controls para los tipos de workitems personalizados la estrategia era similar, aunque no había que insertar nada en el registro si que había que dejar la dll del custom control y un fichero de metadatos .wicc en una ruta especifica, en definitiva, la forma de hacerlo era mediante un paquete de instalación o haciendo el despliegue de forma manual.
La buena noticia es que, una de las nuevas características incluidas en la ultima versión de las Power Tools ha sido una que permite almacenar estos componentes de cliente en el control de código fuente de Team Foundation Server en un directorio especial y luego hacer que se instalen en cada cliente de forma automática si el usuario tiene esta funcionalidad activada. En primer debemos activar esta nueva funcionalidad y para ello tenemos que pulsar sobre la carpeta Team Members con el botón derecho y seleccionar la opción «Personal Settings».
En la pantalla que aparece tenemos varias opciones, pero de momento solo nos centraremos en dos de ellas. La primera, con el texto «Install downloaded custom components», nos permite activar la instalación automática para los componentes de cliente que tengamos en la carpeta especial que comentaba anteriormente y en la que se guardaran los componentes. La segunda de las opciones habilita la validación de los StrongNames de cada uno de los componentes antes de ser instalados. Para llevar a cabo la validación de los StrongNames de los assemblies es necesario que almacenemos todas las claves con las que han sido firmados los assemblies en la ruta «<ApplicationData>MicrosoftTeam Foundation ServerStrongNameKeys». De esta forma se evita que alguien pueda distribuir una dll con código malicioso, por lo tanto es altamente recomendable que si marcamos la casilla para instalar automáticamente los componentes de cliente lo hagamos también con la verificación de los StrongNames.
Por último respecto a esta pantalla solo comentaros que hay un botón con el texto «Download Now» con el que podemos forzar la descarga de los componentes simplemente pulsándolo. Este botón hará un «Get Latest Version» de la carpeta especial que os comentaba y copiará automáticamente los assemblies a la ubicación que les corresponde para que Visual Studio pueda encontrarlos cuando lo requiera.
Con esto habríamos terminado con la configuración que tiene que ver con el despliegue automático de componentes de cliente, ahora solo nos quedaría almacenarlos en el control de código fuente. Si habéis instalado ya las Power Tools, probablemente habréis observado que ahora en el control de código fuente tenemos una carpeta nueva que se llama «TeamProjectConfig». En esta carpeta se guarda la configuración referente a los equipos que hayamos creado, distribuida en varios ficheros.
Para almacenar los componentes de cliente en el control de código fuente y permitir que Visual Studio los instale si tenemos marcada la casilla anterior lo único que tenemos que hacer es crear dos carpetas, cada una de ellas para un tipo componente, «CheckinPolicies» y «CustomControls». Es importante indicar que si tenemos marcada la casilla para la instalación automática, los componentes de cliente se instalarán cada vez que le demos al botón «Download Now».
Por último, si necesitamos tener diferentes versiones de un mismo componente para diferentes versiones de Team Foundation Server, es necesario crear subcarpetas dentro de las carpetas que he comentado anteriormente, utilizando el nombre «1.0» para TFS 2005, «2.0» para TFS 2008 y «3.0» para TFS2010.
Bajo mi punto de vista esta ha sido una gran mejora, ya que la distribución de los componentes de cliente era un tema un poco tedioso. Aún me quedan algunas pruebas por hacer (sobre todo con los StrongName y políticas que usen dlls adicionales) pero en principio, un 10 para el equipo de desarrollo porque me parece una mejora que facilitará mucho el despliegue de las políticas de checkin y los controles personalzados.
