既存のインターフェイスの変更

可能な限り、既存のインターフェイスに変更を加えるのではなく、アプリケーションの新しいインターフェイスを実装します。 既存のインターフェイスの変更を回避できない場合は、新しいメソッドでのみ新しいデータ型を使用します。 新しいデータ型の導入または既存の型の変更は、互換性のない問題の最も一般的な原因です。 RPC ランタイム モデルは、受信アプリケーションが受信するデータの種類を認識していることを前提としているため、データは汎用データの説明なしでネットワークに配置されます。 受信者が送信者がネットワーク上に置いたデータ型とは異なるデータ型を想定すると、スタブによって例外が発生します (または、他のあまり適切でない方法で送信が失敗します)。

RPC インターフェイスは、UUID とそのメジャー バージョン番号とマイナー バージョン番号によって定義されます。 既存のインターフェイスを変更する場合は、インターフェイスの末尾に新しいメソッドを追加し、マイナー バージョン番号を変更する必要があります。 他の場所にメソッドを追加したり、インターフェイスに他の変更を加えたりする場合は、メジャー バージョン番号も変更する必要があります。

現実的には、新しいクライアントは古いサーバーと通信できず、サーバーを更新できないため、マイナー バージョン番号も変更できない場合があります。 RPC ランタイムでは、クライアントがサーバーとのインターフェイスに指定されたメソッドを超えてメソッドを呼び出すと、RPC_S_PROCNUM_OUT_OF_RANGE例外が発生します。 回避策は、バージョン番号を変更せずに、この例外を適切に処理するクライアント コードを記述することです。たとえば、クライアントのパフォーマンスが低下したり、アプリケーションに適した手段が必要になったりします。

既存のメソッドでデータ型を変更する場合は、同様の回避策があります。 分岐がポインターであり、認識されない型の既定のブランチがない共用体がある場合は、新しいデータ型を使用する新しいブランチを追加できます。 これにより、データ構造のサイズは変更されません。 クライアントが新しいサーバーと話すときは、新しいデータ型を使用できます。 ただし、クライアントが古いサーバーと話し合うと、実行時に例外RPC_S_INVALID_TAGが発生します。 この場合も、この例外を適切に処理するためにクライアント コードを記述する必要があります。

DCOM インターフェイスは、その GUID によって識別されます。 DCOM では、インターフェイスは不変と見なされ、変更は、古いインターフェイスから継承する新しいインターフェイスを作成することによってのみ行うことができます。 これらの規則により、クライアントとサーバーの互換性が維持されます。