變更現有的介面

盡可能為您的應用程式實作新的介面，而不是對現有介面進行變更。 如果您無法避免變更現有的介面，請只在新的方法中使用新的資料類型。 引進新的資料類型或修改現有類型是不相容問題最常見的來源。 RPC 執行時間模型假設接收應用程式知道接收的資料類型，因此資料會放在網路上，而不需要一般資料描述。 當收件者預期資料型別與寄件者線上路上放置的資料類型不同時，存根會以其他較不正常的方式引發例外狀況， (或傳輸失敗) 。

RPC 介面是由其 UUID 及其主要和次要版本號碼所定義。 當您變更現有的介面時，您應該在介面結尾新增新的方法，並變更次要版本號碼。 如果您在任何其他位置新增方法，或對介面進行任何其他變更，您也需要變更主要版本號碼。

實際上，有時候您無法變更次要版本號碼，因為新的用戶端將無法與舊伺服器通訊，而且您無法補救伺服器。 當用戶端呼叫方法超出伺服器介面指定的方法時，RPC 執行時間會引發例外狀況RPC_S_PROCNUM_OUT_OF_RANGE。 因應措施是讓版本號碼保持不變，並撰寫用戶端程式代碼以正常方式處理此例外狀況，例如，用戶端會降低其效能，或因應應用程式的任何方式。

變更現有方法中資料類型的特殊案例有類似的因應措施。 如果您有一個 聯集 ，其分支是指標，而且沒有無法辨識類型的預設分支，您可以新增使用新資料類型的新分支。 這不會變更資料結構的大小。 當您的用戶端與新的伺服器交談時，可以使用新的資料類型。 不過，當您的用戶端與舊伺服器交談時，執行時間將會引發例外狀況RPC_S_INVALID_TAG。 同樣地，您必須撰寫用戶端程式代碼，以適當地處理此例外狀況。

DCOM 介面是由其 GUID 所識別。 在 DCOM 中，介面會被視為不可變，而且您只能建立繼承自舊介面的新介面來進行變更。 這些規則可確保用戶端和伺服器保持相容。