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:

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:

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:

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:

¡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:

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?