Ejemplos de cambios incompatibles

Al tratar con cambios incompatibles, la regla general desafortunada es la siguiente: cualquier cambio puede ser incompatible con versiones anteriores, a menos que se entienda muy bien. Esta regla requiere conocimiento de las reglas de NDR. Si no sabe cuál es el NDR, no realice modificaciones. Los ejemplos de cambios que suelen dar lugar a una infracción de acceso en la aplicación, o un BAD_STUB_DATA_EXCEPTION generado por el motor de serialización, son los siguientes:

• Agregar un nuevo método en medio de métodos antiguos.
• Agregar o quitar parámetros de un método.
• Cambiar un atributo, por ejemplo, un atributo de puntero: cambiar [ref] a [unique] o [ptr] o viceversa. Cada tipo de puntero tiene una representación de cable diferente.
• Cambio del tamaño de los datos: de corto a largo, de char a wchar_t (unicode), agregando un campo a una estructura, cambiando el tamaño de una matriz de tamaño fijo.
• Agregar brazos de unión a una unión con una cláusula predeterminada.

Algunos cambios insidiosos o discrepancias no deseadas entre un cliente y un servidor pueden producirse de la siguiente manera:

• Modificar un miembro de un tipo compuesto, como una estructura o una matriz. Por ejemplo, si un CLIENT_ID cambia de un entero a un GUID, una estructura de CLIENT_RECORD con el campo CLIENT_ID deja de ser incompatible. Esto puede ser difícil de detectar si se ejecuta en cascada a través de varios niveles de inserción en un tipo de parámetro remoto real.
• Modificar un tipo importado. El tipo puede provenirse de un componente diferente que no sea remoto directamente, por lo que se pensó que el cambio era compatible.
• El uso de #ifdef en un archivo IDL es una mala idea de si las definiciones de tipo de definición en un archivo IDL son desastres a la espera de que se produzca. Inevitablemente, debido a problemas de compilación u otros problemas, un cliente se compila con un conjunto diferente de defines que el servidor y terminan siendo incompatibles.