¿Hay buenas razones para permitir que AssemblyVersion y AssemblyFileVersion coincidan?

Question

Gendarme tiene un AvoidAssemblyVersionMismatchRule con la siguiente descripción:

Esta regla comprueba que el [AssemblyVersion] coincide con el [AssemblyFileVersion] cuando ambos están presentes en el interior de un ensamblaje. Tener diferentes números de versión en ambos atributos puede ser confuso una vez que se implementa la aplicación.

Por ejemplo, esta regla podría advertir sobre System.dll de Microsoft, que tiene los siguientes atributos:

[assembly: AssemblyVersion("2.0.0.0")] 
[assembly: AssemblyFileVersion("2.0.50727.3053")] 

no estoy de acuerdo con la regla de Gendarme. Después lo haría imposible utiliza un esquema de versiones similar a la utilizada por Microsoft, es decir

• actualización AssemblyFileVersion en cada generación,
• cambio AssemblyVersion sólo en la interfaz pública o cambios de otro modo principales,
• asegúrese de que AssemblyVersion y AssemblyFileVersion comparten un prefijo común,

y creo que este esquema de versiones es la razón por la que el diseño se hizo posible diferenciar entre AssemblyVersion y AssemblyFileVersion en primer lugar.

No se me ocurre una razón por la cual forzar los dos atributos de ensamblaje sean iguales es una buena práctica, ¡pero tal vez tú puedas! Me gustaría conocer sus opiniones.

Si, efectivamente, no hay una buena razón, pronto voy a sugerir que los desarrolladores Gendarme para cambiar la regla para

Esta regla comprueba que el [AssemblyVersion] y [AssemblyFileVersion]tienen un prefijo común, no vacío cuando ambos están presentes dentro de un ensamblaje.

Answer 1

De acuerdo, si coinciden, ¡entonces no tendría que haber dos atributos diferentes para empezar! Pero como dice la regla: podría ser confuso.

AssemblyVersion es más como "La versión de toda su aplicación", mientras que FileVersion es la versión de un archivo individual. Si su Aplicación tiene varios ensamblajes que tienen Ciclos de actualización diferentes por cualquier razón (por ejemplo, Complementos que se actualizan por separado pero que requieren una versión principal específica de la aplicación principal), entonces podría dar a cada uno una Versión de archivo diferente pero tener una Versión de ensamblaje común.

También, a veces, es realmente inconveniente actualizar AssemblyVersion (por ejemplo, SharePoint Workflows y Web Parts son un PITA para actualizar porque esperan una AssemblyVersion específica), por lo que FileVersion se usa a menudo como la versión real.

Answer 2

De acuerdo, esta es una regla tonta. No puede implementar una actualización de corrección de errores para un ensamblado con nombre seguro cuando lo sigue. Por lo demás, hay pocas razones para no hacerlas iguales si realmente tiene que cambiar [AssemblyVersion]. Quizás se supone que no debes usar esa herramienta cuando arregles errores. Irónico.

Answer 3

Creo que la regla tiene sentido en muchos escenarios, ya que .NET Framework considera esencialmente que dos ensamblajes con la misma AssemblyVersion son intercambiables.

Por lo tanto, por ejemplo, una versión anterior está en la caché de descarga y no se sobrescribirá automáticamente con una nueva versión que solo difiere en AssemblyFileVersion.

Esto puede ser confuso para el desarrollador promedio, de ahí la regla.

Por supuesto, si sabes lo que estás haciendo y entiendes las compensaciones, puedes ignorar la regla.