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

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

  • Статья

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

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

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

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