TeamCity + + WiX MSBuild sugerencias de flujo de trabajo necesarios

Question

He estado trabajando en el siguiente paso de mi proyecto de integración continua, que es conseguir TeamCity para construir mi aplicación, automáticamente cambiar el número de versión de todos los conjuntos, y luego crear un instalador .

Un poco de historia primero:

He estado corriendo TeamCity con éxito durante los últimos meses, y se basa mis configuraciones y corre mi NUnit y NCover hace exámenes muy bien.

Me tomé un poco de tiempo investigando instaladores: siempre he odiado InstallShield y nunca lo he considerado para mi aplicación actual. Me gusta NSIS, pero luego me encontré con WiX. No tengo ningún conocimiento íntimo de la arquitectura de MS Installer, que entiendo es peligroso para proyectos complicados, por lo que en algún momento tendré que aprender más al respecto. Sin embargo, después de unos días de preguntas sobre SO, búsqueda de Google y lectura de blogs, tengo un proyecto de WiX que construye, instala, ejecuta la aplicación y desinstala todo limpiamente. ¡Estupendo!

También quería que la configuración de compilación de TeamCity actualizara automáticamente el número de versión de todos mis ensamblajes. Pude simular esta funcionalidad instalando el MSBuild Community Tasks en mi máquina de desarrollo y creando una configuración de Implementación que usa un objetivo BeforeBuild y la tarea FileUpdate para cambiar el número de versión. Eso funciona correctamente, excepto que en mi máquina de desarrollo, no tengo una variable de entorno build_vcs_number_1 para sustituir.

Así que ahí es donde estoy ahora - Necesito que TeamCity haga la actualización, y si bien tiene la variable de entorno build_vcs_number_1, no puedo encontrar la manera de acceder a las tareas de comunidad de WiX MSBuild.

Una publicación que leí recomienda comprobar los destinos de MSBuild en una carpeta SVN. Tengo una carpeta/extlib para este tipo de cosas, así que mis reglas de comprobación TeamCity VCS tienen el siguiente aspecto:

+:tags/2010-10-15=>src 
+:extlib=>extlib 

¿Cómo llego a extlib de una variable de entorno? Cuando ejecuto la construcción, TeamCity se queja (y correctamente) de que no puede encontrar c:\wix30\MSBuildCommunityTasks. La carpeta real es C:\TeamCity\buildAgent\work\3e073d2b74226378\extlib\wix30\MSBuildCommunityTasks. La carpeta se genera automáticamente porque estoy haciendo un checkout en el servidor, por lo que debe haber alguna variable de entorno que establezca TeamCity que pueda usar para obtener la ruta correcta.

Una cosa que debería destacar es que me he vuelto a la configuración de generación -> Propiedades y variables de entorno y encontré la lista desplegable poco intuitivo con todas las variables existentes, y no vi nada de lo que sonaba como una variable que apunta a la camino de trabajo

Una solución posible que puedo pensar es simplemente instalar MSBuild Community Tasks en el servidor de compilación, y luego puedo crear una variable de entorno del sistema a la que se puede acceder por <WixToolPath>.

¿Alguien tiene otras sugerencias?

Answer 1

Veo algunos méritos al tratar de tener las tareas de la comunidad msbuild en SVN (para reducir los requisitos de una máquina de compilación) pero personalmente solo las instalaba en el servidor. Parte importante: actualice su documentación para su servidor de compilación para listar la instalación como un requisito previo. Para mí, utilizo las tareas de la comunidad básicamente en cada msbuild en varios proyectos y scripts de implementación, por lo que mantenerlos todos en SVN es un poco redundante. También tengo WiX instalado en el servidor de compilación.

que hacer algo similar, pero en lugar de un objetivo antes de construir, tengo un archivo de proyecto msbuild más o menos así:

<Target Name="Build"> 
    <CallTarget Targets="UpdateVersionNumbers"/> 
    <MSBuild Projects="Project.sln" Targets="Build"/> 
</Target> 

Mi objetivo UpdateVersionNumbers agarra la revisión de SVN, y luego utiliza una expresión regular y la tarea FileUpdate para cambiar la cuarta parte del número de versión a la revisión SVN.

Luego ejecuto la compilación normal del archivo de solución, y se incluye en el desarrollo de .wixproj. Muy simple, realmente.

---

responder a algunas de sus otras preguntas sin embargo:

• al especificar las rutas, siempre utilizan rutas relativas a la raíz de su solución (dir pago y envío). Entonces, por ejemplo, en este caso, simplemente usaría wix30\MSBuildCommunityTasks. TeamCity ejecuta msbuild con el directorio de trabajo como raíz y, además de eso, no importa dónde usted u otros desarrolladores realicen su pago: las rutas son solo relativas.

• Puede pasar los parámetros en teamcity a msbuild usando los Parámetros de compilación -> Propiedades del sistema. Por ejemplo, agregue una propiedad llamada agentHome que tiene un valor de %system.agent.home.dir% y luego puede hacer referencia a ella en su archivo msbuild como $ (agentHome). Tenga en cuenta si usted también está invocando msbuild de nuevo como en el ejemplo anterior, habría que hacer:

  <MSBuild Projects="Project.sln" Properties="agentHome=$(agentHome)" Targets="Build"/> 
  

  a pasar en realidad esa variable en Project.sln. I piensa pero no estoy seguro de que msbuild ejecute en un archivo .sln también pasará todas las propiedades a todos los proyectos individuales, por lo que puede acceder a él en su evento antes de la construcción.

---

Nota al margen de los instaladores (Hace poco pasó por lo mismo que hizo): Me instalados en WiX 3.0, y aunque no es del todo la curva de aprendizaje a ella, funciona bien. Comenzamos un nuevo flujo de desarrollo y comenzamos a usar VS2010 y .NET 4. Bueno, WiX 3.0 no es compatible con VS2010, por lo que necesitábamos WiX 3.5 (que todavía está en Beta, aunque el state of it seems much better now than it was a few months ago, pero todavía están rezagados. es la naturaleza del código abierto, a veces). Tuve algunos pain getting WiX 3.0 and 3.5 to install together, pero finalmente lo resolvió.

La frustración de esto sin embargo (entre la incompatibilidad, las betas escamosas (de hace algunos meses) y el lento progreso general) realmente me desconectó de WiX (sin ofender a los chicos que trabajan en WiX, pero solo quiero un instalador y no quiero involucrarmeTenga en cuenta que son muy frustrated también). Agregue a eso que el producto que necesito para el próximo requiere un instalador mucho más complejo, y WiX parece demasiado trabajo. Acabo de construir mi instalador usando AdvancedInstaller, y solo tomó un par de días, y hasta ahora ha estado funcionando bien (aunque ahora estamos en las primeras etapas de desarrollo, pero comenzando la implementación y pruebas continuas). Los precios de AI son razonables (todavía estamos en la versión de prueba ahora) pero los compraré en los próximos días.

Estoy SEGURO de que el tiempo que pasé aprendiendo IA fue MUCHO menos de lo que me gustaría gastar aprendiendo WiX, y luego tratar de hacer que haga todo lo que necesito. Es un poco inevitable aprender ALGO sobre cómo funciona Windows Installer, pero no es necesario profundizar demasiado.

Answer 2

Odio cuando esto sucede ... escribe una pregunta larga, solo para encontrar algo que me perdí minutos después.

Me pregunto si esto es:

supongo que mi pregunta ahora es - puedo realmente utilizar% system.agent.work.dir% en mi .wixproj? Lo intentaré ahora.