Reglas para la compatibilidad con la clase C#/evitar cambios de rotura

Question

Estoy trabajando en un ensamblado C# 3.5 que es consumido por muchas aplicaciones diferentes en un entorno de servidor empresarial. Me gustaría agregar algunas propiedades a una clase C# existente (no abstracta) y mantener la compatibilidad con clientes actuales sin recompilar. Es un ensamble de nombre fuerte 3.5. Las aplicaciones cliente existentes no se volverán a compilar. En su lugar, utilizamos ensamblajes de políticas de editores para redirigir los clientes existentes a la versión actualizada.

¿Cuáles son las reglas para mantener este tipo de compatibilidad con las versiones anteriores?

Estoy buscando un conjunto de reglas con las que pueda validar mis cambios de código.

Después de mis intentos actuales de actualizar la clase, los clientes lanzan una excepción "La definición del manifiesto del conjunto localizado no coincide con la referencia de ensamblaje".

Answer 1

La mejor referencia es la respuesta de Justin: A definite guide to API-breaking changes in .NET

@Justin - si alguna vez publicar esto como una respuesta, te voy a dar el cheque.

Answer 2

Debe mantener la misma versión de ensamblaje (es decir, no aumentarla en las compilaciones) - consulte AssemblyVersionAttribute in MSDN.

Además, podría aprovechar las redirecciones de enlace de ensamblaje, pero esto implica cambios en el archivo de configuración que no espero sean deseables en su caso.

Answer 3

En este punto, el error que está obteniendo no está relacionado con la compatibilidad entre clases, sino más bien con un problema al cargar el ensamblado; consulte The located assembly's manifest definition does not match the assembly reference si ayuda.

Agregar propiedades/métodos para exisitng class debería estar bien para compatibilidad con versiones anteriores. Eliminar campos/métodos/propiedades, cambiar de clase a estructura, cambiar la clase base definitivamente no lo es. La modificación de constantes, valores enum es peligroso.