Поделиться через

Примеры несовместимых изменений

  • Статья

При работе с несовместимыми изменениями правило большого пальца выглядит следующим образом: любое изменение может быть обратно несовместимым, если оно не очень хорошо понято. Для этого правила требуется знание правил NDR. Если вы не знаете, что такое недоставка, не вносите изменения. Ниже приведены примеры изменений, которые обычно приводят к нарушению доступа в приложении или BAD_STUB_DATA_EXCEPTION, вызванному подсистемой маршалинга:

  • Добавление нового метода в середине старых методов.
  • Добавление или удаление параметров из метода.
  • Изменение атрибута, например атрибута указателя: изменение [ref] на [уникальный] или [ptr] или наоборот. Каждый тип указателя имеет разное представление провода.
  • Изменение размера данных: от короткого к длинному, от char к wchar_t (Юникод), добавление поля в структуру, изменение размера массива фиксированного размера.
  • Добавление объединяемого оружия в объединение с помощью условия по умолчанию.

Некоторые коварные изменения или непреднамеренные несоответствия между клиентом и сервером могут произойти следующим образом:

  • Изменение элемента составного типа, например структуры или массива. Например, если CLIENT_ID меняется с целочисленного на GUID, структура CLIENT_RECORD с полем CLIENT_ID становится несовместимой. Это может быть трудно определить, если каскадно пройти несколько уровней внедрения в фактический удаленный тип параметра.
  • Изменение импортированного типа. Тип может поступать из другого компонента, который не находится на удаленном уровне напрямую, поэтому изменение считается совместимым.
  • Использование #ifdef в IDL-файле является плохой идеей для определений типов ifdef в IDL-файле. Это аварийное ожидание. Неизбежно из-за сбоев сборки или других сбоев клиент компилируется с набором определений, отличным от набора определений сервера, и они в конечном итоге несовместимы.