Pregunta

Tengo el siguiente escenario: Una aplicación se construye a través de la IDE y por medio de un script de construcción. La escritura de la estructura se utiliza para la configuración inicial (ir a buscar dependencias, la creación de medio ambiente), para generar los binarios y para el proceso de integración continua. Quiero que los binarios que tienen como AssemblyFileVersion el mes y día en construcción, y la revisión de SVN en la revisión. Esto hace que los AssemblyInfo.cs cambiar en cada revisión, lo que crea una gran cantidad de ruido en el registro de control de código fuente. Puedo ignorar los archivos, pero entonces, como parte de la instalación que había necesidad de regenerar esos.

Me gustaría saber si alguien tiene alguna otra idea, o ¿qué hacer en este caso.

¿Fue útil?

Solución

En este momento estoy decidí por una solución inspirada en la respuesta de Andy White:

  • AssemblyInfo.cs es generado por la tarea AssemblyInfo http://msbuildtasks.tigris.org/ y se mantiene fuera de la estructura de control de origen.
  • La versión es [importante]. [Menores]. [Meses] [días]. [Revisión SVN]. Mayor y menor se ajustan manualmente, los otros son gestionados por el script de construcción. El Comunidad pack incluye tanto las tareas necesarias para obtener la revisión svn copy de trabajo y fecha.

La desventaja:

  • Cuando alguien obtiene una copia fresca del configuración blanco de la escritura de la estructura se debe ejecutar, de lo contrario Visual Studio se quejará de los archivos que faltan. Este es un problema que me gustaría eliminar en el futuro.

Otros consejos

Creo que una práctica común para AssemblyInfo.cs es simplemente generar dinámicamente como parte del proceso de construcción, en lugar de mantener un archivo estático alrededor.

Mediante la generación, se puede utilizar cualquier configuración arbitrarias / configurables que desee.

Creo que tiene una tarea de NAnt <asminfo> para este propósito. Supongo que hay algo similar para MSBuild también. O simplemente podría escribir un script de generación de archivo personalizado y utilizarlo para empujar un AssemblyInfo.cs personalizados en su construcción.

Sólo nos actualizamos AssemblyInfo en el tronco después de una RTM / RTW / GA / (Cualquiera que sea :) versión de lanzamiento.

Nuestra noche / Beta / RC / GC / (:) Lo que acaba de tomar construye una copia de los AssemblyInfo.cs actualizados (a partir de una copia de trabajo en el servidor IC) en su rama o una etiqueta apropiada. Nosotros usamos Subversion, y se puede rama / etiqueta en una copia de trabajo con los cambios no confirmados.

Esto nos permite mantener tanto la versión correcta de AssemblyInfo para la noche / Beta acumulación en la rama o una etiqueta, y sólo tocamos AssemblyInfo en el maletero después de un lanzamiento final ha tenido lugar. El servidor de compilación tiene un interruptor para indicarle que debe comprometerse a este tronco en este tipo de construcción.

Fwiw, conducimos todo desde los scripts de MSBuild, utilizando diferentes valores para las propiedades establecidas para cada tipo de proyecto, pasa a través de nuestro servidor de compilación (CruiseControl.NET).

[EDIT] También tenga en cuenta que la versión de desarrollador de AssemblyInfo no se actualiza (a menos que cambie manualmente), por lo que no hay ruido de AssemblyInfo modificado en cada generación. Dejamos que controlan los desarrolladores MAJOR.MINOR , el servidor controla la creación creación , y nos vamos de revisión de control de calidad para enlazar a su propio sistema (ya que los mismos son ignorados por Wix / MSI de todos modos) .

Si usted no marca los AssemblyInfo.cs cambiado de nuevo en control de código fuente, entonces ¿por qué hay ruido?

Me gustaría recomendar el uso de un único valor de AssemblyFileVersion de todo el diseño, y que o bien comprobar en un solo archivo que contiene esa versión, y / o etiqueta de la construcción con el número de versión. De esa manera, no se sentirá la necesidad de comprobar en varios archivos AssemblyInfo.cs modificados.

También utilizamos una etapa de generación para crear el AssemblyInfo [cs | vb]. Archivos, aunque simplemente usamos una copia de plantilla del archivo como la fuente, y luego un pequeño script en Perl para analizar esa plantilla, reemplace la cadena de versión y generar la salida final.

El problema de este sistema es que los proyectos de VB parecen cargar constantemente el archivo AssemblyInfo, lo que significa que el proyecto tendrá un error cuando se carga por primera, incluso antes del paso PreBuild puede ejecutar para crear el archivo AssemblyInfo.vb. No hemos encontrado una solución a ese problema todavía - El que tiene entendimiento, me encantaría escucharlo ...

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top