c# - ¿Mejores prácticas para nombrar y versionar el ensamblado?
.net assemblies (4)
Estoy buscando algunas buenas prácticas para nombrar conjuntos y versionarlos. ¿Con qué frecuencia incrementa las versiones mayor o menor?
En algunos casos, he visto lanzamientos directamente desde la versión 1.0 a la 3.0. En otros casos, parece estar atascado en la versión 1.0.2.xxxx.
Esto será para un ensamble compartido utilizado en múltiples proyectos en toda la compañía. Esperando algunas buenas entradas.
Alguna buena información de este artículo en el blog de Suzanne Cook en MSDN (publicado el 2003-05-30):
Cuándo cambiar las versiones de archivo / ensamblaje
En primer lugar, las versiones de archivo y las versiones de ensamblaje no necesitan coincidir entre sí. Recomiendo que las versiones de los archivos cambien con cada compilación. Pero no cambie las versiones de ensamblaje con cada compilación solo para que pueda distinguir entre dos versiones del mismo archivo; usa la versión del archivo para eso. Decidir cuándo cambiar las versiones de ensamblaje requiere una discusión sobre los tipos de construcciones que se deben considerar: envío y no envío.
Desarrollos sin envío
En general, recomiendo que las versiones de ensamblado que no son de envío sean iguales entre las compilaciones de envío. Esto evita problemas de carga de ensamblaje fuertemente nombrados debido a discrepancias de versión. Algunas personas prefieren usar la política del editor para redirigir nuevas versiones de ensamblaje para cada compilación. Sin embargo, recomiendo esto para las versiones que no sean de envío: no evita todos los problemas de carga. Por ejemplo, si un socio copia x su aplicación, es posible que no sepa instalar la política del editor. Entonces, su aplicación se romperá para ellos, a pesar de que funciona bien en su máquina.Pero, si hay casos en que las diferentes aplicaciones en la misma máquina necesitan vincularse a diferentes versiones de su ensamblaje, recomiendo darles a esas construcciones diferentes versiones de ensamblaje para que se pueda usar la correcta para cada aplicación sin tener que usar LoadFrom / etc.
Generaciones de envío
En cuanto a si es una buena idea cambiar esa versión para enviar compilaciones, depende de cómo quiera que funcione el enlace para los usuarios finales. ¿Desea que estas construcciones estén una al lado de la otra o en el lugar? ¿Hay muchos cambios entre las dos versiones? ¿Van a romper algunos clientes? ¿Te importa que los rompa (o quieres obligar a los usuarios a usar tus actualizaciones importantes)? En caso afirmativo, debería considerar incrementar la versión de ensamblaje. Pero, nuevamente, considere que hacerlo demasiadas veces puede ensuciar el disco del usuario con ensamblajes desactualizados.Cuando cambia las versiones de su ensamblaje
Para cambiar las versiones codificadas a la nueva, recomiendo establecer una variable para la versión en un archivo de encabezado y reemplazar la codificación rígida en las fuentes con la variable. Luego, ejecute un pre-procesador durante la compilación para poner la versión correcta. Recomiendo cambiar las versiones inmediatamente después del envío, no antes, para que haya más tiempo para detectar errores debido al cambio.
La versión semántica tiene un conjunto de pautas y reglas sobre cómo aplicar esto (y cuándo). Muy simple de seguir y simplemente funciona.
Lo primero que recomendaría es familiarizarme con las diferencias entre la versión de ensamblaje y la versión de archivo. Desafortunadamente, .NET tiende a tratar esto como lo mismo cuando se trata de los archivos AssemblyInfo, ya que generalmente solo coloca AssemblyVersion y permite que FileVersion tenga el mismo valor por defecto.
Como dijiste que esto es un ensamblado compartido, supongo que te refieres a que se comparte a nivel binario (no al incluir el proyecto en varias soluciones). Si ese es el caso, usted debe ser muy deliberado sobre el cambio de la versión de ensamblaje, ya que eso es lo que .NET usa para nombrar el ensamblaje (para permitirle colocarlo en el GAC) y también constituye el "nombre completo del ensamblado". Cuando la versión del ensamblaje cambia, puede tener cambios importantes para las aplicaciones que la usan sin agregar entradas de redirección de ensamblaje en el archivo app.config.
En cuanto a la denominación, creo que depende de cuáles son las reglas de nomenclatura de su empresa (si las hay) y el propósito de la biblioteca. Por ejemplo, si esta biblioteca proporciona funcionalidad "central" (o nivel de sistema) que no es específica de ningún producto o línea de negocio en particular, puede nombrarla como:
CompanyName.Framework.Core
si es parte de una biblioteca más grande, o simplemente
CompanyName.Shared
CompanyName.Core
CompanyName.Framework
En cuanto a cuándo incrementar los números de versión, sigue siendo bastante subjetivo y depende de lo que considere que representa cada parte del número de compilación. El esquema predeterminado de Microsoft es Major.Minor.Build.Revision, pero eso no significa que no pueda crear sus propias definiciones. Lo más importante es ser coherente en su estrategia y asegurarse de que las definiciones y reglas tengan sentido en todos sus productos.
En casi todos los esquemas de versiones que he visto, las dos primeras porciones son Major.Minor. El número de versión principal por lo general aumenta cuando hay cambios grandes y / o cambios de última hora, mientras que el número de versión menor generalmente aumenta para indicar que algo cambió y que no fue un cambio de última hora. Los otros dos números son considerablemente más subjetivos y pueden ser la "construcción" (que a menudo es un valor de fecha de serie o un número de actualización secuencial que cambia cada día) y la "revisión" o número de parche. También los he visto invertir (dando Major.Minor.Revision.Build) donde build es un número secuencialmente incrementado de un sistema de compilación automatizado.
Tenga en cuenta que las versiones principal y secundaria del ensamblaje se usan como el número de versión de la biblioteca de tipo cuando se exporta el ensamblaje.
Finalmente, eche un vistazo a algunos de estos recursos para obtener más información:
http://msdn.microsoft.com/en-us/library/51ket42z.aspx
http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx
Una forma de definir su versión es dar significado semántico a cada parte:
- Vaya de Nx a N + 1.0 cuando la compatibilidad se rompe con la nueva versión
- Vaya de NM a N.M + 1 cuando se agregan nuevas funciones que no rompen la compatibilidad
- Ir de NMX a NMX + 1 cuando se agregan correcciones de errores
Lo anterior es solo un ejemplo: querrá definir las reglas que tengan sentido para usted. Pero es muy bueno para los usuarios saber rápidamente si se esperan incompatibilidades simplemente mirando la versión.
Ah, y no te olvides de publicar las reglas que propones para que la gente sepa qué esperar.