2009-04-20 14 views
7

¿Qué cambios en un ensamblaje de nombre fuerte requieren un cambio en AssemblyVersionAttribute? Claramente, cambiar la API pública de una manera que podría requerir que un cliente tenga que hacer un cambio de código requiere un aumento en AssemblyVersion. Pero, ¿qué pasa con los cambios en la API pública que no requieren cambios de código en el cliente? Por ejemplo:.NET: con respecto a AssemblyVersion, ¿qué define la compatibilidad binaria?

  • ¿la adición de una clase pública o interfaz?
  • la adición de un miembro público a una clase pública o interfaz? (EDITAR: drscroogemcduck señala correctamente que añadir un miembro a una interfaz sería para todos los implementadores. Tonto.)
  • ¿Aumento de la visibilidad de un miembro de la clase?

Tiene que haber documentación definitiva de esto en algún lugar de MSDN (o, conociendo a MS, en el blog personal de MSSE). Pero simplemente no puedo encontrarlo. ¡Por favor ayuda!

Respuesta

4

Es bastante fácil ... siempre y cuando los tipos no cambien (en su diseño público o protegido) y las firmas de métodos no cambien (agregar métodos o tipos está bien), el JIT debería poder vincular el DLL .

Dicho esto, creo que incluso si se hace trabajo que debe no hacerlo. Cree una nueva versión y use una política para asignar la versión anterior a la nueva, si es necesario. De lo contrario, volverás directo al DLL ... y estoy seguro de que no quieres eso.

+0

Dos preguntas: * me puede apuntar a la documentación - oficiales o no - en su primera declaración? * ¿te importaría elaborar tu segunda declaración? En este caso particular, quiero aumentar la visibilidad, desde lo interno a lo público, del contenido de una clase pública. No está claro para mí cómo esto podría llevar a (la versión GAC de) DLL infierno. – cero

+0

Primero: Tendría que buscarlo. Básicamente, el JIT compila métodos tan tarde como sea necesario. La unión final ocurre solo cuando el JIT compila el método, por lo que si el método está allí y coincide con la firma, funcionará, esa es mi experiencia. Sin embargo, agregar métodos a interfaces públicas no sería una buena idea, ya que eso podría llevar a métodos faltantes. – Lucero

+0

En cuanto a la segunda instrucción, cambiar el código y dejar la identidad de su ensamblador igual puede llevar a un comportamiento diferente. Por ejemplo, cuando realiza una reflexión, especifica si desea encontrar miembros privados o públicos. Si uno solo utiliza el enlace "privado", ya no encontrará el ctor (en su caso), y el usuario recibirá un mensaje de error a pesar de que él (y el tiempo de ejecución) cree que es la misma versión ...y puede confundir el tiempo de ejecución si la asamblea también estuvo en el GAC. No lo hagas – Lucero

1

Agregar métodos a una interfaz no debería estar bien porque los proveedores antiguos no implementarán los nuevos métodos.

+0

Buen punto. Editando la publicación original. :) – cero

1

Microsoft agrega nuevos métodos/clases en librerías .NET en las versiones de service pack sin cambiar AssemblyVersion (aún 2.0.0.0/3.0.0.0). Microsoft solo cambia AssemblyFileVersion. Por ejemplo, en .NET 2.0 SP1, se agregó la estructura DateTimeOffset.

¿Debería recomendarnos esta práctica porque Microsoft hace esto? Es confuso.

Cuestiones relacionadas