.net - imagen - en html, el atributo alt se emplea para

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

Question

Los atributos AssemblyVersion y AssemblyFileVersion son la forma incorporada 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.

Entonces, me gustaría preguntar, ¿qué formas se han determinado para hacer el mejor trabajo de tener números de versión que reflejen 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

AssemblyVersionAttribute es parte de la identidad de un ensamblado. Cambiar eso significa que se trata de un ensamblaje diferente y que los programas vinculados a ese ensamblaje deben 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 2

En mi proyecto actual, utilizamos el número de revisión de Subversion como la parte menos significativa (compilación) del número de versión, y utilizamos un script de Nant para crear el archivo AssemblyInfo del proyecto. 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 revisara para cada compilación y provocaba conflictos al fusionar. 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 3

En un trabajo anterior, donde utilizamos Subversion, tuve un script nant ejecutado sobre ccnet para extraer la versión del repositorio y lo usé como el número final.

En este trabajo, usamos VSS (obturador), por lo que no es realmente una opción, por lo que tenemos una política de actualización manual, con las siguientes pautas:

• Importante: cambios significativos o más (> 25%) en la funcionalidad o la interfaz.
• Menor: pequeños cambios o adiciones en funcionalidad o interfaz.
• Build: pequeños cambios que rompen la interfaz.
• Revisión: se corrige una construcción que no cambia la interfaz.

También mantenemos sincronizadas las versiones de Assembly y File. 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 el Explorador de Windows.

Answer 4

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

Answer 5

Tendemos a incrustar la fecha de lanzamiento (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 6

Usamos el control de versiones de subversion y los buildscripts actualizan la información de la versión del ensamblado, por lo que checkins de origen controla el control de versiones.

Answer 7

Tenemos nuestro servidor de compilación CruiseControl.NET que integra el número de lista de cambios forzosa en AssemblyFileVersion ; esto nos permite rastrear el código fuente de cualquier ensamblado creado por el servidor de compilación. (Siempre construimos desde la rama principal)

Para los ensamblajes a los que los clientes harán referencia, dejamos constantVersion a menos que haya cambios de última hora, en cuyo caso incrementamos la versión para asegurarnos de que el código del cliente se vuelva a compilar contra la 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 (abcd) 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.