¿Cuál es la mejor manera de usar los atributos de versiones de ensamblaje?

Question

Los atributos AssemblyVersion y AssemblyFileVersion son la forma integrada de manejar los números de versión para ensamblados .NET. Si bien el marco proporciona la capacidad de tener las partes menos significativas de un número de versión (compilación y revisión, en términos de Microsoft) determinadas automáticamente, creo que el método es bastante débil, y sin duda tiene muchas otras.

Así que me gustaría preguntar, ¿De qué manera se han determinado a hacer el mejor trabajo de tener números de versión que reflejan mejor la versión real de un proyecto? ¿Tiene un script de precompilación que establece parte de la versión a la fecha y hora, o la versión del repositorio para su copia de trabajo de un proyecto? ¿Simplemente usas la generación automática provista por el framework? ¿O algo mas? ¿Cuál es la mejor manera de administrar versiones de archivo/ensamblaje?

Answer 1

En mi proyecto actual, se utiliza el número de revisiones Subversion como la parte menos significativa (acumulación) del número de versión, y se utiliza una secuencia de comandos Nant para crear el proyecto AssemblyInfo archivo. Usamos el mismo número de versión para los atributos AssemblyVersion y AssemblyFileVersion. (Las otras tres partes son major.minor.point, donde major.minor se incrementará cada vez que haya un cambio en el esquema de la base de datos, y el punto se incrementará para cada versión.)

Comenzamos con el número de compilación simplemente incrementado, pero eso requería que el archivo de versión se registrara para cada compilación, y provocaba conflictos al fusionarse. Cuando resultó ser inviable, comenzamos a usar CruiseControl.NET para generar el número de compilación, pero eso dificultó la reproducción manual de compilaciones específicas. Finalmente, pasamos al esquema actual (revisión de Subversion).

Nota: Desafortunadamente con .NET, no es posible recrear perfectamente una compilación a partir de una revisión anterior, porque los compiladores .NET codifican la marca de tiempo actual en el archivo objeto al compilar. Cada vez que compila el mismo código, obtiene un archivo de objeto diferente.

Answer 2

Nuestros scripts de construcción insertan el número del conjunto de cambios de TFS en la versión. De esa forma, sabemos exactamente qué comprobaciones hay en la compilación.

Answer 3

Nos utilizar el control de versiones de la subversión y tienen actualizar los buildscripts la información de la versión de montaje, por lo confirmaciones fuente de control de versiones.

Answer 4

La AssemblyVersionAttribute es parte de la identidad de un ensamblado. Cambiar eso significa que es un ensamblaje diferente y que los programas vinculados a ese ensamblaje necesitan ser recompilados/vinculados o que se debe aplicar una política de versión. No encontramos esa apelación, por lo que elegimos aumentar solo AssemblyFileVersion para cada hotfix y solo cambiar AssemblyVersion para cada versión principal. Somos conscientes de que esta decisión nos trae de vuelta el infierno de win32 dll. Aumentamos AssemblyFileVersion para cada compilación y etiquetamos/etiquetamos el sistema de control de versiones con esa versión para saber de qué fuente proviene el binario.

Answer 5

En un trabajo anterior, donde se utilizó la subversión, que tenía un guión Nant correr CCNet para extraer la versión del repositorio y usados ​​que a medida que el número final.

En este trabajo, nosotros utilizar VSS (obturador), así que no es realmente una opción, así que tenemos una política de actualización de forma manual, con las siguientes directrices:

• Mayor: significativa (> 25%) cambios o adiciones en funcionalidad o interfaz.
• Menor: pequeños cambios o adiciones en la funcionalidad o la interfaz.
• Generar: pequeños cambios que rompen la interfaz.
• Revisión: se corrige una compilación que no cambia la interfaz.

También guardamos el Conjunto & las versiones de archivo en sincronización. La versión de ensamblado se puede leer fácilmente mediante programación, mientras que la versión de archivo se puede mostrar como una columna en el modo Detalles en Windows Explorer.

Answer 6

Tendemos a incrustar la fecha de liberación (o compilación) en el conjunto. Por ejemplo, si se construye hoy, la versión sería "2008.10.06" (el script de construcción lo actualiza).

Answer 7

Tenemos nuestro servidor de compilación CruiseControl.NET incruste el número de lista de cambios obligatoria en el AssemblyFileVersion - esto nos permite rastrear el código fuente de cualquier ensamblado construido por el servidor de compilación. (Siempre construimos desde la sucursal principal)

Para los ensamblajes a los que los clientes harán referencia dejamos la constante AssemblyVersion a menos que haya cambios bruscos, en cuyo caso incrementamos la versión para asegurarnos de que el código del cliente se vuelva a construir contra el nueva versión.

Answer 8

Veo muchas publicaciones aquí sobre el uso del número de revisión de subversión como un componente de la versión de ensamblaje. Cuidado: los 4 números de versión disponibles en Windows (a.b.c.d) están limitados a 16 bits (máximo = 65535). El número de revisión de subversión puede superar fácilmente este límite, especialmente si aloja varios proyectos en el mismo repositorio.