RPC 和 COM 的版本控制理論

只有兩個完全無問題的方法支援新功能，而沒有連線相容性問題的風險：

• 根據規則變更介面版本;這可防止新的用戶端與舊伺服器通訊，而且可能無法防止舊的用戶端與新伺服器通訊。 本節稍後會厘清這一點。
• 介紹處理新功能的不同介面。

標準 RPC 介面是由 GUID 和版本號碼組合所識別;COM 介面是由其 GUID 所識別。 版本包含主要和次要部分。 對於具有相同 GUID 和不同版本號碼的標準介面，只有在主要版本相同，且用戶端不高於伺服器的次要版本時，才能連線。

因此，變更 RPC 介面 GUID 會中斷連線相容性，而變更介面名稱則不會。

在標準 RPC 中，已妥善定義升級和延伸模組的路徑，基本上要求新的方法只會在介面結尾新增，而新的類型只用于新的方法。 如果需要這類新增專案，則必須增加次要版本。 任何其他變更都需要主要版本的變更，因為用戶端和伺服器軟體在連線上不相容。 遵守這些規則可確保每當新的用戶端與舊伺服器之間有連線，反之亦然，這兩端都完全相容。

對於 COM 介面，無法使用版本屬性。 建立新的介面並從舊介面繼承，相當於在 RPC 中操作版本。 一般而言，COM 的最佳方法是為擴充的功能建立新的介面。 次要版本的對等專案是繼承自舊介面的新介面。 變更舊方法或舊資料類型需要全新的 COM 介面，也就是不會繼承自舊介面的介面。

針對 COM， QueryInterface 函式是檢查伺服器是否支援介面的已建立方法;因此，用戶端可以與舊版或新版本介面通訊的情況，可以輕鬆地解決。