¿Hay buenas razones para dejar AssemblyVersion y AssemblyFileVersion partido?

Question

Gendarme tiene un AvoidAssemblyVersionMismatchRule con la siguiente descripción:

  

Esta regla comprueba que el [AssemblyVersion] partidos la [AssemblyFileVersion] cuando ambos están presentes en el interior de un ensamblaje. Que tienen diferentes números de versión en ambos atributos puede ser confuso cuando se despliega la aplicación.

Por ejemplo, esta regla advertiría en 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,
• cambiar AssemblyVersion sólo en la interfaz pública o de otra manera importante los cambios,
• asegurarse de que AssemblyVersion y compartir AssemblyFileVersion 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 el primer lugar.

No puedo encontrar una razón por la que obligó tanto el montaje atribuye a ser igual es una buena práctica, pero tal vez usted puede! Yo estaría interesado en sus opiniones.

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

  

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

Answer 1

De acuerdo, si deben coincidir entonces no tendría que haber dos atributos diferentes, para empezar! Pero a medida que la regla dice:. 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 la aplicación tiene varios ensamblados que tienen diferentes ciclos de actualización por cualquier razón (por ejemplo, los plugins que se actualizan por separado, pero que requieren de una gran versión específica de la aplicación principal), entonces se podría dar a cada una FileVersion diferentes pero tienen una AssemblyVersion común.

También, a veces, es realmente un inconveniente para actualizar el AssemblyVersion (por ejemplo, elementos web de SharePoint Flujos de trabajo y son un PITA para actualizar porque esperan un AssemblyVersion especificada), por lo que la FileVersion se utiliza a menudo como la versión real.

Answer 2

De acuerdo, esto es una regla tonta. No se podía implementar una actualización de corrección de errores de acogida para un montaje llamado fuerte cuando lo siguen. En caso contrario hay pocas razones para no hacer ellos lo mismo si en realidad se tiene que cambiar el [AssemblyVersion]. Tal vez no se supone utilizar esa herramienta cuando corregir errores. Irónica.

Answer 3

Creo que la regla tiene sentido en muchos escenarios, ya que el .NET Framework considera esencialmente dos conjuntos con el mismo AssemblyVersion a ser intercambiables.

Así, por ejemplo, una versión antigua está en el caché de descarga no se sobrescribe automáticamente por una nueva versión que sólo difieren en AssemblyFileVersion.

Esto puede ser confuso para el desarrollador promedio, por lo tanto, la regla.

Por supuesto, si usted sabe lo que está haciendo y entender las ventajas y desventajas, puede ignorar la regla.