互換性のない変更の例

互換性のない変更に対処する場合、残念な経験則は次のとおりです。非常によく理解されていない限り、すべての変更は下位互換性がない可能性があります。 このルールには、NDR ルールに関する知識が必要です。 NDR が何であるかがわからない場合は、変更しないでください。 通常、アプリケーションでアクセス違反が発生する変更、またはマーシャリング エンジンによって発生したBAD_STUB_DATA_EXCEPTIONの例を次に示します。

• 古いメソッドの途中に新しいメソッドを追加する。
• メソッドのパラメーターの追加または削除。
• 属性の変更 (たとえば、ポインター属性): [ref] を [unique] または [ptr] に変更するか、またはその逆に変更します。 各ポインターの種類には、異なるワイヤ表現があります。
• データのサイズを変更する:short から long、char から wchar_t (Unicode)、構造体にフィールドを追加する、固定サイズ配列のサイズを変更する。
• 既定の句を使用して共用体に共用体の腕を追加する。

クライアントとサーバーの間に予期しない変更や意図しない不一致が発生する場合があります。

• 構造体や配列など、複合型のメンバーを変更する。 たとえば、CLIENT_IDが整数から GUID に変更された場合、CLIENT_ID フィールドを持つCLIENT_RECORD構造体は互換性がなくなります。 これは、実際のリモート パラメーター型に複数のレベルの埋め込みを介してカスケードされているかどうかを検出するのが困難な場合があります。
• インポートされた型の変更。 型は、直接リモートではない別のコンポーネントから来ている可能性があるため、変更は互換性があると考えられていた。
• IDL ファイルで#ifdefを使用することは、IDL ファイル内の ifdef 型定義に対して不適切な考え方です。これは、発生を待機している障害です。 必然的に、ビルドやその他の不具合により、クライアントはサーバーとは異なる定義のセットでコンパイルされ、最終的に互換性がありません。