Exemplos de alterações incompatíveis

Ao lidar com alterações incompatíveis, a regra de ouro infeliz é a seguinte: qualquer alteração pode ser incompatível com versões anteriores, a menos que seja muito bem compreendida. Essa regra requer conhecimento das regras de NDR. Se você não souber o que é a NDR, não faça modificações. Exemplos de alterações que normalmente resultam em uma violação de acesso no aplicativo ou um BAD_STUB_DATA_EXCEPTION gerado pelo mecanismo de marshaling são os seguintes:

• Adicionar um novo método no meio de métodos antigos.
• Adicionar ou remover parâmetros de um método.
• Alterando um atributo, por exemplo, um atributo de ponteiro: alterando [ref] para [exclusivo] ou [ptr] ou vice-versa. Cada tipo de ponteiro tem uma representação de fio diferente.
• Alterando o tamanho dos dados: de curto para longo, de char para wchar_t (unicode), adicionando um campo a uma estrutura, alterando o tamanho de uma matriz de tamanho fixo.
• Adicionando braços de união a uma união com uma cláusula padrão.

Algumas alterações insidiosas ou incompatibilidades não intencionais entre um cliente e um servidor podem ocorrer da seguinte maneira:

• Modificando um membro de um tipo composto, como uma estrutura ou uma matriz. Por exemplo, se um CLIENT_ID mudar de um integral para um GUID, uma estrutura CLIENT_RECORD com o campo CLIENT_ID se tornará incompatível. Isso pode ser difícil de detectar se foi colocado em cascata por vários níveis de inserção em um tipo de parâmetro remoto real.
• Modificando um tipo importado. O tipo pode ser proveniente de um componente diferente que não é remoto diretamente, portanto, a alteração foi considerada compatível.
• Usar #ifdef em um arquivo IDL é uma má ideia para definir definições de tipo ifdef em um arquivo IDL— é um desastre esperando para acontecer. Inevitavelmente, devido ao build ou a outras falhas, um cliente é compilado com um conjunto diferente de defines do que o servidor e eles acabam sendo incompatíveis.