En la anotación anterior utilicé los eventos que se generan antes y después de la construcción (pre-build y post-build) para ejecutar, primero una rutina que genera el código para restaurar un respaldo de una base de datos en el ambiente de desarrollo; y finalmente ejecutar el código generado previo al despliegue de la actualización de un proyecto de base de datos. Ahora voy a explorar una alternativa más flexible y poderosa: personalizar el proceso de construcción de MSBuild.
Los entornos para desarrollo integrados, se llaman así porque integran diversas herramientas que se utilizan durante la elaboración de software. Una de esas herramientas es la que construye el producto de software, utilizo el verbo construir para referirme a este proceso, ya que con la evolución de los entornos y herramientas, ahora la construcción involucra más que la compilación del código fuente en código objeto, el enlace de bibliotecas y la creación de un programa ejecutable o biblioteca de rutinas.
En el caso de Visual Studio y de .Net Framework en Windows, la herramienta encargada de orquestar la construcción se llama MSBuild. De hecho, MSBuild es parte de .Net Framework y técnicamente no se necesita Visual Studio para crear asambleas o programas que utilicen CLR (Ejecutor de Lenguaje Común, por sus siglas en inglés). Más bien, es al revés, Visual Studio requiere de MSBuild para construir los ejecutables y asambleas.
Un proceso de construcción se define en MSBuild a partir de los siguientes elementos en términos generales:
- Elementos
- Conjuntos de elementos
- Tareas
- Condiciones
La manera de expresar estos elementos es a través de un archivo XML, en el caso de Visual Studio el archivo de proyecto contiene además de las características utilizadas por el entorno, la definición de tareas requeridas para construir el proyecto.
De entrada, MSBuild cuenta con una amplia gama de tareas predefinidas. Estas van desde lo más simple como copiar un archivo, hasta la invocación del compilador de recursos de .Net para generar las asambleas satélite de recursos para globalización. Si no es suficiente, existe la tarea Exec que permite ejecutar un comando arbitrario. De hecho, los eventos pre-build, post-build son tareas Exec y simplemente ejecutan la línea de comandos que se captura a través de los atributos del proyecto. Además, se pueden definir otras tareas a través de una asamblea, que contenga clases que implementen algunas interfaces. Una discusión más detallada será tema de futuras entradas. Por ahora, me limitaré a decir que podemos modificar el archivo de proyecto, para agregar algunas tareas que dependan del paso build y que a su vez, sean requisitos del paso deploy.
En la siguiente entrada, detallaré paso a paso, como moví las líneas de comando de los eventos pre-build y post-build a un par de tareas que dependen de la ejecución exitosa del paso build, que se ejecutan sólo cuando lo indique una variable definida en el archivo de proyecto, y que sean requisitos previos del paso deploy.
No hay comentarios:
Publicar un comentario