Lo que rompe una interfaz binaria (dll) .net

Question

Considere dos .net dlls. El primero, " application.dll " Contiene la lógica de negocio principal y el código de acceso a datos. El segundo, " webservice.dll " consiste principalmente en WebMethods que se vinculan a objetos y métodos con application.dll con el fin de proporcionar llamadas de servicio web al código existente.

¿Qué cambios (por ejemplo, agregar nuevas clases, agregar un nuevo campo o método a una clase existente, etc.) pueden y no pueden realizarse en application.dll sin requerir una recompilación de webservice.dll?

Answer 1

La mayoría de las cosas estarán bien; Algunas cosas que lo romperán:

• Eliminando * los tipos que se usan (a menos que esté usando el reenvío de tipos)
• Eliminando * los métodos que se utilizan (incluido el constructor)
• Cambiar la firma de los métodos (que se utilizan)
• Cambiar campos públicos a propiedades (que se utilizan)
• Cambiando los internos de serialización si se usa la serialización
• Agregar un método a una interfaz, donde la segunda dll tiene un tipo que implementa esa interfaz
• Agregar un método abstracto a una clase base que se hereda en la segunda dll
• Casi cualquier cosa interna si se utiliza (ab) la reflexión hacky
• Agregar restricciones a un tipo / método genérico
• Marcar un tipo como sellado cuando se heredó en la segunda dll
• Agregar un campo a una struct si la persona que llama usa la inicialización de miembros en lugar de la inicialización del constructor

(la eliminación incluye cambiar la accesibilidad a algo que no es público)

Answer 2

Técnicamente, el nombre lo romperá (nombre y versión y token de clave en el caso de conjuntos con nombre fuerte). De lo contrario, el marco intentará cargar y usar la DLL, y esto funcionará más o menos bien hasta que llegue a un tipo o firma de método diferente, un tipo faltante, etc. Pero tenga en cuenta que el uso de nombres va directamente al infierno de DLL (o sus problemas).

Sugiero leer más sobre control de versiones del ensamblaje para tener una idea cómo resolver tales problemas.

Answer 3

puede realizar cualquier cambio en application.dll sin necesidad de volver a compilar webservice.dll siempre que no esté llamando a las nuevas clases, funciones [agregadas en application.dll]. Si desea consumir cualquiera de los cambios de su application.dll en webservice.dll, entonces tiene que recompilar el webservice.dll

Por supuesto, si cambia la firma o el nivel de acceso de cualquiera de los métodos o propiedades en application.dll que utiliza websrvice.dll, se romperá su código en el servicio web.