互通的一般考量
更新：2007 年 11 月
所有在 Managed 與 Unmanaged 程式碼之間產生的呼叫必須交涉由每一個個別的程式撰寫模型所強制的需求。Managed 與 Unmanaged 程式撰寫模型在許多方面上有所差異。下表顯示每一個模型的定義特性。
特性 |
Unmanaged 模型 |
Managed 模型 |
|---|---|---|
編碼模型 |
以介面為主 |
以物件為主 |
識別 |
GUID |
強式名稱 (Strong Name) |
錯誤處理機制 |
HRESULT |
例外狀況 |
型別相容性 |
二進位標準 |
型別標準 |
型別定義 |
型別程式庫 |
中繼資料 |
型別安全 |
非型別安全 (Type Safety) |
選擇性安全 |
版本控制 |
不變性 |
彈性 |
有些程式撰寫模型特性具有您可以檢視的關聯實體 (Entity)，例如型別程式庫和中繼資料。有些您可以當成引數傳遞，例如 GUID 和強式名稱。而其他特性更具概念性；您一定會考量它們對應用程式設計的影響，不過您將不會在 Managed 與 Unmanaged 模型之間遇到這些特性的直接對應。
以下章節將更詳細地說明每一個特性。
編碼模型
Unmanaged 物件永遠會透過介面進行通訊；Managed 物件與類別可以直接傳遞資料，而不需要實作介面。根據預設值，當物件或類別沒有實作介面時，COM Interop 會產生一個類別介面，以透過介面來公開 Managed 功能給 COM。
錯誤處理機制
COM 方法通常會傳回 HRESULT，表示呼叫成功或失敗。Managed 程式碼包含例外狀況。根據預設值，COM Interop 會將 Managed 例外狀況對應到失敗的 HRESULT。識別
GUID 會識別特定的 Unmanaged 型別，並且不為該型別提供位置資訊。除了型別名稱之外，強式名稱還包含唯一的組件名稱。因為組件名稱可以唯一識別型別，您可以在多個組件之間重複使用型別名稱。組件也會引入發行者金鑰 (Publisher Key)、版本和位置資訊給 Managed 型別。互通服務會產生 GUID，並依要求進行強式命名。一般舊資料結構 (PODS)
平台叫用無法用於依照值傳回包含建構函式的結構或類別。一般來說，包含非 PODS 項目的使用者定義型別應由參考傳回。PODS 是資料結構，僅包含被動的欄位值集合，如 ISO/IEC 標準 14882「程式語言 — C++」所定義。這些資料結構不包含建構函式、複製指派運算子，或本身不是 PODS 的非靜態資料成員。型別相容性
型別在 Managed 與 Unmanaged 程式碼之間 (甚至在不同語言之間) 的差異極大。型別定義
如果您習慣於使用型別程式庫，您知道它們只包含公用 (Public) 型別。此外，型別程式庫是選擇性的。在 Managed 程式撰寫模型中，型別資訊對所有型別來說都是強制性的。互通服務所提供的工具，可將型別程式庫轉換為組件中的中繼資料，以及將中繼資料轉換為型別程式庫。型別安全
Unmanaged 編譯器 (Compiler) 在指標型別 (Pointer Type) 上不提供型別檢查，使得程式碼易受潛在有害活動的影響。一般來說，Managed 程式碼需要更高的信任層級。雖然程式碼因其不安全行為而有所限制，但是程式設計人員還是可以繼續在 Managed 程式碼中使用指標。互通服務可防止不受信任的 Managed 程式碼存取 Unmanaged 程式碼。版本控制
COM 介面是不變的。如果變更介面，必須以新的 GUID 將它重新命名。Managed 型別可以逐步形成，同時保持相同名稱。