Compatibilidad retroactiva de interfaces DLL y COM — Tabla de decisión sobre qué cambios rompen al lado que llama

«Para esta corrección, ¿basta con reemplazar la DLL, o también hay que recompilar el lado que llama?» — al mantener una DLL común o un componente COM al que hacen referencia varias aplicaciones, esta es la pregunta que hay que responder en cada versión. Si la respuesta es incorrecta, el EXE antiguo que corre en el cliente puede dejar de arrancar, o peor aún, puede seguir arrancando mientras los resultados de los cálculos cambian silenciosamente.

Lo complicado es que esta decisión suele tomarse con la sensación de «esto parece peligroso», sin más. En realidad, casi siempre se puede determinar de forma mecánica qué cambio rompe la compatibilidad. Las DLL nativas tienen las reglas de exportación y de convención de llamada; COM tiene la regla explícita de que «las interfaces son inmutables»¹; y .NET cuenta con la lista de reglas de cambio de compatibilidad que la propia Microsoft usa en el desarrollo de sus bibliotecas .NET.²

En este blog ya explicamos los fundamentos de COM en «Qué es COM / ActiveX / OCX» y su filosofía de diseño en «Qué es COM - por qué el diseño de COM en Windows sigue siendo hermoso». En este artículo se organiza, para cada una de las DLL, COM y los ensamblados .NET, qué cambio rompe al lado que llama, en forma de tabla de decisión, y se detalla también el procedimiento a seguir cuando resulta inevitable romper la compatibilidad.

Terminología usada en este artículo

Para leer la tabla de decisión hace falta manejar algunos términos a nivel binario. Se tratan en detalle en cada capítulo, pero conviene repasarlos primero en una línea para facilitar la lectura.

1. La conclusión, primero

• La compatibilidad tiene tres niveles: compatibilidad binaria (funciona sin recompilar), compatibilidad de código fuente (funciona si se recompila) y compatibilidad de comportamiento (el comportamiento no cambia). No basta con “no requiere recompilación = seguro”; hay que evaluar también la compatibilidad de comportamiento.³
• La regla básica para las DLL nativas es: “agregar exportaciones es seguro; modificar o eliminar exportaciones existentes es una ruptura”. La firma de las funciones, la convención de llamada y el diseño de las estructuras son, en sí mismos, el contrato binario.
• Las interfaces COM son inmutables una vez publicadas. Agregar, eliminar o reordenar métodos después de la publicación viola la especificación; cualquier cambio se agrega como una nueva interfaz con un nuevo IID (IFoo → IFoo2).⁴¹
• Los clientes VB6/VBA, al usar enlace anticipado (early binding), graban en tiempo de compilación la posición dentro de la vtable, por lo que son los que más fácilmente se rompen ante un cambio en el diseño de la interfaz.
• En .NET, Microsoft publica sus propias reglas de cambio de compatibilidad, que definen qué cambios en una API pública son destructivos. No solo la eliminación de métodos o los cambios de firma; incluso agregar virtual o cambiar el nombre de un parámetro se clasifican como cambios destructivos.²
• El versionado semántico es una convención que dice “si hay un cambio destructivo, sube la versión mayor”, pero solo funciona si se declara primero una definición de qué es un cambio destructivo.⁵ La tabla de decisión de este artículo puede usarse como esa definición.
• Cuando es inevitable romper la compatibilidad, se avanza en el orden: ofrecer lo nuevo y lo antiguo en paralelo → período de obsolescencia → inventario de quién llama → retiro. El principio es no reemplazar de golpe.

2. Los tres niveles de compatibilidad — quién se rompe y cuándo

Lo que se llama en general “compatibilidad retroactiva” en realidad se divide en tres niveles. Incluso la documentación oficial de .NET clasifica los cambios destructivos desde la perspectiva de la compatibilidad de código fuente, la compatibilidad binaria y la compatibilidad de comportamiento.³

Estos tres niveles son más fáciles de entender si se piensan como anidados.

［Compatibilidad de comportamiento］el comportamiento no cambia        ← la más externa
  └─［Compatibilidad de código fuente］funciona si se recompila
       └─［Compatibilidad binaria］funciona sin recompilar   ← la más interna

Cuanto más interno es el nivel, más estrictas son sus condiciones, y cuanto mejor se preserva el nivel interno, menor es el esfuerzo para el lado que llama. Lo importante de estos tres niveles es que el nivel externo puede romperse aunque el nivel interno permanezca intacto. Por ejemplo, una modificación que cambia el significado del valor de retorno de una función existente puede romper solo la compatibilidad de comportamiento, sin afectar ni la compatibilidad binaria ni la de código fuente. Este tipo de cambio no produce ni errores de enlace ni errores de compilación, por lo que es la fila de la tabla de decisión que más fácilmente se pasa por alto.

A la inversa, en un entorno donde todos los que llaman tienen el código fuente y pueden recompilar simultáneamente (por ejemplo, un sistema interno en un único repositorio), basta con preservar la compatibilidad de código fuente y de comportamiento, y se puede dejar fuera el requisito de compatibilidad binaria. “¿Existe, entre quienes llaman a mi DLL, algún binario que no se pueda recompilar?” es la primera bifurcación a la hora de leer la tabla de decisión.

3. Tabla de decisión de compatibilidad para DLL nativas (C/C++)

La compatibilidad de una DLL nativa está determinada por la tabla de exportación, la convención de llamada y el diseño de la memoria. Cómo se busca y se carga una DLL ya se explicó en «Cómo funciona la resolución de nombres de DLL en Windows», pero la compatibilidad una vez que la carga se realizó con éxito se puede evaluar con la siguiente tabla.

Esta tabla sirve para decidir «qué se va a cambiar a partir de ahora», pero en la práctica es más frecuente usarla al revés: «este síntoma reportado por el cliente, ¿a qué fila de cambio corresponde?». A continuación se relaciona cómo se manifiesta en la práctica cada una de las filas anteriores.

La directriz de diseño que se desprende de esta tabla no ha cambiado nunca: limitar el límite (boundary) al ABI de C (funciones extern "C" y estructuras simples) y realizar las extensiones agregando funciones. Esto vale igual si la DLL nativa se genera desde C#: la superficie de exportación tratada en «Cómo llamar a una DLL de C# Native AOT desde C/C++» también se gestiona siguiendo esta tabla.

3.1 La convención cbSize — la sabiduría de Win32 para hacer extensibles las estructuras

El remedio clásico frente a «agregar un miembro a una estructura rompe la compatibilidad» es la convención de Win32 de colocar un campo de tamaño al principio de la estructura. El lado que llama coloca en cbSize el tamaño de la estructura que conocía en tiempo de compilación, y la DLL usa ese tamaño para determinar «de qué generación de la estructura tiene conocimiento este lado que llama».

typedef struct KS_CONFIG {
    DWORD cbSize;      // el lado que llama establece sizeof(KS_CONFIG)
    DWORD dwMode;
    DWORD dwTimeout;
    // los miembros futuros siempre se agregan al final
} KS_CONFIG;

// Lado de la DLL: determina la generación con cbSize y usa un valor por defecto para los llamadores antiguos
if (pConfig->cbSize >= FIELD_OFFSET(KS_CONFIG, dwTimeout) + sizeof(DWORD)) {
    timeout = pConfig->dwTimeout;   // llamador nuevo
} else {
    timeout = DEFAULT_TIMEOUT;      // llamador antiguo
}

El motivo de usar FIELD_OFFSET(KS_CONFIG, dwTimeout) + sizeof(DWORD) en lugar de sizeof(KS_CONFIG) para la comprobación es que así se puede evaluar, miembro por miembro final, si la generación llega hasta dwTimeout. Si se evaluara con sizeof, en el momento en que se agregue un nuevo miembro al final en el futuro, la condición se volvería más estricta y clasificaría como antiguos incluso a los llamadores de la generación que «conoce dwTimeout pero no el nuevo miembro». Evaluando de esta forma miembro por miembro, no hace falta reescribir las comprobaciones existentes cada vez que se extiende la estructura.

De hecho, la estructura NOTIFYICONDATA de la API de Windows gestiona sus generaciones exactamente con este mecanismo, y está documentado oficialmente que el valor asignado a cbSize permite mantener la compatibilidad con versiones antiguas de Shell32.dll.⁸ Si se incluye cbSize desde la primera versión en las estructuras públicas de una DLL propia, las extensiones futuras pasan de ser un «cambio destructivo» al «lado seguro de la tabla de decisión». Aun así, los miembros nuevos siempre deben agregarse al final, y sigue prohibido cambiar el tipo o el orden de los miembros existentes. Además, en las estructuras que se usan como salida, la responsabilidad de la DLL aumenta: la escritura y la inicialización deben mantenerse siempre dentro del rango del cbSize recibido. Si se escribe incondicionalmente el nuevo sizeof, se desborda el búfer pequeño reservado por un llamador antiguo, y la propia DLL provoca la ruptura que esta convención debía prevenir.

4. La regla de oro de las interfaces COM — prohibido modificar una vez publicadas

COM es la tecnología que dio la respuesta más clara a este problema. Según la especificación de COM, las interfaces siguen estas reglas:

• La interfaz tiene un IID (identificador de interfaz) único.¹
• La interfaz es inmutable. Una vez creada y publicada, no se debe cambiar ninguna parte de su definición.¹
• Agregar o eliminar métodos, o cambiar su semántica, no significa «una nueva versión de la interfaz antigua», sino que implica crear una nueva interfaz con un IID distinto.⁴

El motivo de ser tan estricto es que la interfaz COM, en la práctica, es un diseño binario: la vtable (la tabla de punteros a función). Los clientes en C++ o VB6 graban en tiempo de compilación una posición, como «el tercer slot es GetName». Si se inserta un método después de la publicación, el cliente antiguo, sin ningún error, termina llamando a otro método. Por eso COM eliminó de la especificación la operación misma de «modificar» y, en su lugar, estableció el siguiente procedimiento de extensión.

// v1: ya publicada. No se modifica nunca más
[object, uuid(1111....)]
interface ICalc : IUnknown {
    HRESULT Add([in] long a, [in] long b, [out, retval] long* result);
};

// v2: nueva interfaz con un nuevo IID. Extiende ICalc por herencia
[object, uuid(2222....)]
interface ICalc2 : ICalc {
    HRESULT AddChecked([in] long a, [in] long b, [out, retval] long* result);
};

El IDL anterior es un ejemplo ilustrativo en el que uuid se abrevió como 1111...., y tal como está no se puede compilar. En la práctica hay que escribir el GUID completo generado con la herramienta de creación de GUID incluida en Visual Studio (guidgen) o con el comando uuidgen. Usar el mismo GUID en dos interfaces impide distinguir los contratos, así que cada vez que se agrega una interfaz hay que generar uno nuevo.

La clase de implementación (coclass) implementa tanto ICalc como ICalc2: los clientes antiguos siguen usando ICalc como hasta ahora, y los clientes nuevos solicitan ICalc2 mediante QueryInterface. La teoría oficial de versionado de RPC/COM también lo organiza así: «una nueva interfaz que hereda de la antigua equivale a una actualización de versión menor; si se cambian los métodos o tipos existentes, se necesita una interfaz completamente nueva que no herede (equivalente a una actualización de versión mayor)».⁹ Lo que hace posible este esquema es que QueryInterface permite al lado que llama comprobar de forma segura, en tiempo de ejecución, qué se admite. La belleza del diseño de este mecanismo se analizó en «Qué es COM».

4.1 El reparto de roles entre CLSID, ProgID e IID

Al pensar en el versionado de COM, conviene separar el rol de tres tipos de identificadores.¹⁰

• El IID es el identificador de la interfaz (el contrato). Si el contrato cambia, siempre debe ser un IID nuevo.
• El CLSID es el identificador de la clase de implementación. Reemplazar la implementación manteniendo el mismo CLSID es libre, siempre que se respete el contrato de las interfaces ya publicadas.
• El ProgID es un alias legible para humanos (KomuraSoft.Calc.1) que se usa para buscar en el registro la correspondencia con el CLSID. Existe la convención de mantener tanto un ProgID con número de versión como un ProgID independiente de la versión (KomuraSoft.Calc) que siempre apunta a la última versión; este último se asocia a la versión más reciente mediante CurVer.¹⁰

Es decir, «la actualización de versión de la implementación» pertenece al mundo del CLSID y del ProgID, mientras que «el cambio de contrato» pertenece al mundo del IID, y no deben mezclarse. Si se quiere evitar por completo el registro en el registro de Windows, esa opción se trata en «Qué es Reg-Free COM».

4.2 Por qué los clientes VB6/VBA se rompen con especial facilidad

Cuando se usa un componente COM desde VB6 o VBA mediante una referencia establecida (enlace anticipado), la llamada se resuelve leyendo la biblioteca de tipos en tiempo de compilación. El enlace anticipado es la forma recomendada porque habilita IntelliSense y la verificación de tipos, además de ejecutarse más rápido¹¹, pero a cambio queda fuertemente acoplado al diseño de la biblioteca de tipos. No solo si cambia la vtable de la interfaz: incluso un simple cambio en las definiciones de la biblioteca de tipos se manifiesta como «al abrir el proyecto, la referencia estaba rota» o como errores 430/438 en tiempo de ejecución.

Por eso, en los componentes que tienen como llamadores a VB6, VBA o macros de Excel, hay que respetar la regla de inmutabilidad de la interfaz con la máxima rigurosidad. La biblioteca de tipos también tiene una versión (mayor.menor), que se debe subir y gestionar cada vez que se amplía el contrato. La generación de la biblioteca de tipos cuando se expone desde .NET a VBA con tipado fuerte se explica en «Cómo usar una DLL de .NET 8 desde VBA con tipado - exposición COM y dscom TLB». Por otro lado, los clientes de enlace tardío que solo usan CreateObject resuelven por nombre y son resistentes a los cambios de diseño, pero de igual manera sufren el impacto de los cambios de significado de los métodos (compatibilidad de comportamiento).

5. Compatibilidad de los ensamblados .NET — evaluación mecánica con reglas oficiales

En .NET, Microsoft publica las «reglas de cambio para la compatibilidad» que usa en el desarrollo de sus propias bibliotecas .NET, y clasifica cada cambio como permitido (✔️), prohibido (❌) o a evaluar (❓).² Como se indica explícitamente que se pueden adoptar tal cual como criterio de evaluación para las bibliotecas propias, aquí se extraen las filas principales.

La única fila de esta tabla marcada ❓ (a evaluar) es «agregar un miembro a una interfaz», y es también la que más dudas genera en la práctica. Con una implementación predeterminada (DIM: Default Interface Members, miembros de interfaz predeterminados) se puede agregar un miembro sin dejar sin implementar a las clases existentes, pero las reglas oficiales enumeran las siguientes condiciones.²

• El requisito mínimo del lado consumidor sube a .NET Core 3.0 / C# 8.0. Como DIM se introdujo en esa versión, en el momento en que se agrega una implementación predeterminada quedan fuera los usuarios que utilizan un runtime anterior. .NET Framework queda excluido, así que en cualquier biblioteca donde todavía quede aunque sea un cliente sobre .NET Framework, esta mitigación no se puede usar.
• Hay lenguajes que no admiten DIM. Como .NET se usa desde varios lenguajes, en las interfaces implementadas desde un lenguaje distinto de C# no se puede contar con la implementación predeterminada.
• Hay situaciones en las que el runtime no puede determinar qué implementación predeterminada invocar. En configuraciones donde intervienen varias interfaces, la resolución de la implementación predeterminada puede volverse ambigua.
• A partir de C# 13, agregar un miembro de instancia predeterminado a una interfaz implementada por un ref struct es un cambio destructivo a nivel de código fuente. Como un ref struct no admite boxing ni conversión al tipo de la interfaz, no puede recurrir a la implementación predeterminada, y los miembros de instancia deben implementarse siempre de forma explícita.

Por otro lado, agregar un miembro estático, no abstracto y no virtual sí está permitido.² Si «se quiere agregar un miembro, pero entre los usuarios todavía queda .NET Framework», lo más seguro es no tocar la interfaz y, con el mismo enfoque que COM en el capítulo 4, agregar una nueva interfaz, o evaluar primero si se puede sustituir por un método de extensión.

No es tan simple como el «la interfaz de COM es inmutable», pero la filosofía es la misma: la API pública es un contrato; agregar al contrato está permitido, pero modificar el contrato existente no lo está. Y precisamente el hecho de que «cambios que a primera vista parecen seguros», como los métodos virtuales o los nombres de parámetros, estén clasificados del lado destructivo es la razón por la que hay que decidir con una tabla y no por intuición.

5.1 El nombre seguro y los tres números de versión

Los ensamblados de .NET tienen varios números de versión, cada uno con un rol distinto.¹²

• AssemblyVersion: la única versión que usa el runtime para identificar y cargar el ensamblado. En los ensamblados con nombre seguro, el CLR de .NET Framework exige una coincidencia exacta, así que cada vez que se sube requiere una redirección de enlace en el lado que llama (.NET/.NET Core acepta automáticamente versiones superiores). La guía oficial propone reflejar en AssemblyVersion únicamente la versión mayor para reducir la necesidad de redirecciones.
• FileVersion (AssemblyFileVersion): solo es visible en las propiedades del Explorador y no afecta el comportamiento del runtime. Se recomienda usarlo para registrar el número de compilación de la CI.
• InformationalVersion: una cadena libre pensada para humanos. Registra la versión del paquete en formato semver o el hash de commit del origen.

En definitiva, en la práctica resulta más manejable una estructura de tres capas: «la declaración de compatibilidad se hace con la versión del paquete/producto (semver), AssemblyVersion refleja solo la versión mayor, y FileVersion permite rastrear la compilación».

6. Cómo asignar números de versión — semver solo funciona si existe una «definición»

El versionado semántico (semver) se puede resumir en tres líneas: subir MAJOR ante un cambio incompatible, MINOR ante una funcionalidad nueva compatible con versiones anteriores, y PATCH ante una corrección de errores compatible con versiones anteriores.⁵

Lo que suele pasarse por alto es que el primer requisito de la especificación de semver es que «el software que usa semver debe declarar su API pública».⁵ Si no se declara qué es la API pública, no existe un criterio para juzgar qué es un «cambio incompatible», y la decisión de subir o no la versión mayor queda librada al ánimo de quien esté a cargo. En muchos de los equipos donde semver no funciona, lo que se omitió no fue la forma de numerar, sino esta declaración.

Para las DLL de distribución interna, una operación realista adopta la siguiente forma.

1. Declarar el alcance de la API pública — en una DLL nativa, las funciones exportadas y los encabezados públicos; en COM, el IDL/la biblioteca de tipos; en .NET, los tipos y miembros públicos. Se deja escrito explícitamente que «todo lo demás es implementación interna y puede cambiar sin previo aviso».
2. Adoptar una definición de cambio destructivo — se colocan en el repositorio, como «definición propia de la empresa», las tablas de decisión de los capítulos 3 y 5 de este artículo, junto con las reglas de cambio de .NET.²
3. Automatizar la evaluación — en .NET, las herramientas Package Validation / ApiCompat permiten comprobar mecánicamente la compatibilidad binaria con la versión anterior.¹³ Esto elimina el «seguramente esté bien» de las revisiones.
4. Incluir un campo de compatibilidad en las notas de la versión — se registra siempre uno de estos tres valores: «no requiere recompilación / se recomienda recompilar / hay un cambio destructivo». Es un mecanismo para dar por escrito, antes de que se pregunte, la respuesta a la pregunta inicial de «¿basta con reemplazar el archivo?».

7. Procedimiento cuando es inevitable romper la compatibilidad

Cuando resulta indispensable un cambio que la tabla de decisión clasifica como «destructivo», se avanza mediante la provisión en paralelo, no mediante un reemplazo directo.

1. Ofrecer lo nuevo y lo antiguo en paralelo — en COM, se agrega IFoo2 y se conserva IFoo (capítulo 4). En una DLL nativa, se agrega una función nueva (FooEx) o se mantienen en paralelo una nueva DLL con otro nombre. En .NET, se publica como un nuevo paquete con la versión mayor incrementada, y la versión mayor anterior continúa recibiendo solo correcciones de errores.
2. Establecer un período de obsolescencia — en .NET, el atributo [Obsolete] permite emitir una advertencia en tiempo de compilación. En nativo/COM, se declara mediante comentarios en el encabezado y en las notas de la versión, indicando explícitamente la fecha prevista de retiro. El punto clave es fijar una fecha, no decir simplemente «se eliminará en algún momento».
3. Hacer un inventario de quién llama — se elabora una lista de «quién sigue llamando a la API antigua» a partir de la búsqueda de código fuente interno, los registros de distribución del instalador y, en el caso de COM, el estado de referencias en el registro. Si aquí se encuentran binarios que no se pueden recompilar (herramientas de empleados que ya se fueron, aplicaciones de terceros), se extiende la vida de la API antigua solo para ese caso, o se tiende un puente con un wrapper.
4. Eliminar la API antigua — se elimina solo después de confirmar, mediante el inventario, que no queda ningún llamador, y se sube la versión mayor.

Este procedimiento tiene un costo. Y por eso, paradójicamente, la mayor medida de compatibilidad es diseñar la API lo más pequeña posible desde la primera publicación, teniendo en cuenta la tabla de decisión (lo que no se publica no genera obligación de compatibilidad).

8. Resumen

• La compatibilidad se piensa en tres niveles: binaria, de código fuente y de comportamiento. Aunque no se requiera recompilar, la compatibilidad de comportamiento puede romperse.³
• En las DLL nativas, «agregar es seguro; modificar las exportaciones, firmas o el diseño de las estructuras existentes es destructivo». Se deja margen de extensión en las estructuras incluyendo cbSize.⁸
• Las interfaces COM son inmutables una vez publicadas. Los cambios se agregan como una nueva interfaz con un nuevo IID (IFoo2), y se distinguen mediante QueryInterface.¹⁴⁹ Cuando hay clientes VB6/VBA con enlace anticipado, esto se respeta con especial rigor.
• En .NET se puede evaluar de forma mecánica con las reglas oficiales de cambio de compatibilidad. Hay que prestar atención a que cambios «aparentemente seguros», como la virtualización, el cambio de nombre de parámetros o el sellado (sealed), están clasificados como destructivos.²
• Es realista una estructura de tres capas: AssemblyVersion solo con la versión mayor, FileVersion para rastrear la compilación y semver para declarar la compatibilidad.¹²
• semver solo funciona si se declara una definición de la API pública y de los cambios destructivos.⁵ Se adopta la tabla de decisión como esa definición y se verifica automáticamente con herramientas como Package Validation.¹³
• Al romper la compatibilidad, se sigue el orden provisión en paralelo → período de obsolescencia → inventario → eliminación. No reemplazar de golpe es lo que protege al EXE antiguo que corre en el cliente.

Artículos relacionados

• Qué es COM / ActiveX / OCX - diferencias y relación explicadas
• Qué es COM - por qué el diseño de COM en Windows sigue siendo hermoso
• Cómo usar una DLL de .NET 8 desde VBA con tipado - exposición COM y dscom TLB
• Cómo funciona la resolución de nombres de DLL en Windows - orden de búsqueda y SxS
• Qué es Reg-Free COM - el mecanismo para usar COM sin registro
• Cómo llamar a una DLL de C# Native AOT desde C/C++

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa del diseño de compatibilidad de DLL, componentes COM y bibliotecas .NET referenciados por otros sistemas, del inventario de la API pública y la definición de una política de versionado, y del diseño e implementación de extensiones que no rompen a los clientes existentes (el método IFoo2, la provisión en paralelo).

• Aprovechamiento de activos existentes y soporte de migración
• Modernización y mantenimiento de software Windows existente
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Basta con agregar una función a la DLL para no tener que recompilar el lado que llama?

Si solo se agrega una función exportada, la regla general es que los llamadores existentes siguen funcionando sin cambios, porque mientras no se modifiquen el nombre, la firma, la convención de llamada ni el número ordinal de exportación de las funciones existentes, la resolución de la importación se sigue cumpliendo como hasta ahora. Sin embargo, si se agrega un miembro a una estructura que reserva y pasa el lado que llama, o si se cambia el significado del valor de retorno o del código de error de una función existente, la compatibilidad de comportamiento puede romperse aunque funcione sin recompilar. La regla básica es: «agregar una función es seguro; modificar la firma existente es destructivo».

¿Por qué no se debe agregar un método a una interfaz COM después de publicarla?

Porque la regla de la especificación de COM establece que, una vez publicada, una interfaz COM es inmutable. La interfaz es un contrato de diseño binario, la vtable (la secuencia de punteros a función), y si se insertan, eliminan o reordenan métodos, el binario antiguo termina llamando a otro método distinto en la posición que grabó en tiempo de compilación. Agregar al final no cambia la posición de los slots existentes, pero entonces puede darse el accidente de que un cliente nuevo obtenga un componente antiguo pensando que ya tiene los métodos «agregados», y termine invocando un slot que no existe; por eso tampoco se permite agregar manteniendo el mismo IID. Si se quiere ampliar la funcionalidad, se agrega una nueva interfaz con un nuevo IID (IFoo2) y se deja intacta la IFoo existente. El lado que llama puede determinar de forma segura, mediante QueryInterface, si el componente admite la interfaz nueva o solo la antigua.

¿Cómo se diferencian y se usan AssemblyVersion, FileVersion e InformationalVersion en .NET?

AssemblyVersion es la única versión que usa el runtime para identificar y cargar el ensamblado; con nombre seguro, .NET Framework exige una coincidencia exacta, por lo que cada vez que se sube hace falta una redirección de enlace. Por eso, la guía oficial propone una operación en la que solo se refleja la versión mayor. FileVersion solo se muestra en las propiedades del Explorador y no afecta el comportamiento del runtime, por lo que es adecuada para registrar, por ejemplo, el número de compilación de la CI. InformationalVersion es una cadena libre pensada para humanos, que registra la versión en formato semver o el hash de commit.

¿Adoptar el versionado semántico (semver) resuelve los problemas de compatibilidad?

No se resuelve solo con semver. semver es una convención que dice «si hay un cambio incompatible con versiones anteriores, sube la versión mayor», pero como requisito previo exige declarar «qué es la API pública y qué es un cambio destructivo». Si solo se asignan números de versión sin esta definición, el criterio varía según la persona y el sistema no funciona. semver cobra sentido recién cuando se adopta, como «la definición propia de cambio destructivo», un criterio como la tabla de decisión de este artículo para las DLL nativas, o las reglas de cambio de compatibilidad de Microsoft para .NET, y se lo incorpora en el procedimiento de publicación.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.