共用方式為

RPC 和 COM 的版本控制理論

  • 發行項

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

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

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

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

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

對於 COM 介面，無法使用 version 屬性。 建立新的介面並從舊介面繼承，相當於在 RPC 中管理版本。 一般而言，COM 中最好的方法是建立擴充功能的新介面。 次要版本的等效項是從舊介面繼承的新介面。 變更舊方法或舊數據類型需要全新的 COM 介面，這是一個不會繼承自舊介面的介面。

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