類別的預設封送處理
類別只能由 COM Interop 來封送處理，且永遠會封送處理為介面。在某些情況下，用來封送處理類別的介面稱為類別介面。如需以您所選擇的介面覆寫類別介面的詳細資訊，請參閱類別介面簡介。
將類別傳遞給 COM
將 Managed 類別傳遞給 COM 時，Interop 封送處理器會自動以 COM Proxy 將類別包裝，並且將 Proxy 所產生的類別介面傳遞給 COM 方法呼叫。接著 Proxy 會委派類別介面上的所有呼叫回到 Managed 物件。Proxy 也會公開其他沒有被類別明確實作的介面。Proxy 會自動實作介面，如代表類別的 IUnknown 和 IDispatch。
將類別傳遞給 .NET 程式碼
一般而言，在 COM 中不會使用 Coclass 做為方法引數。反而通常會以預設的介面代替 Coclass 傳遞。
在將介面傳遞給 Managed 程式碼時，Interop 封送處理器會負責以適合的包裝函式來包裝介面，以及將包裝函式傳遞給 Managed 方法。決定要使用的包裝函式可能有點困難。不論物件實作多少個介面，COM 物件的每一個執行個體都具有單一且唯一的包裝函式。例如，實作五個不同介面的單一 COM 物件只會有一個包裝函式。相同的包裝函式會完全公開五個介面。如果建立 COM 物件的兩個執行個體，則會建立包裝函式的兩個執行個體。
由於包裝函式透過其存留期 (Lifetime) 來維護相同的型別，在第一次透過封送處理器傳遞物件所公開的介面時，Interop 封送處理器必須識別正確的包裝函式。封送處理器會查看物件所實作的其中一個介面來識別物件。
例如，封送處理器會決定應該使用類別包裝函式來包裝已傳遞給 Managed 程式碼的介面。當透過封送處理器第一次傳遞介面時，封送處理器會檢查介面是否來自已知的物件。這個檢查會發生在兩種情況下：
其他 Managed 物件正在實作的介面已經傳遞給 COM 其他位置。封送處理器能夠立即識別 Managed 物件所公開的介面，而且能夠以提供實作 (Implementation) 的 Managed 物件來比對介面。接著 Managed 物件會傳遞給方法，並且不需要任何包裝函式。
已經被包裝的物件正在實作介面。為了判斷是否為這種狀況，封送處理器會為其 IUnknown 介面查詢物件，並且比較已傳回的介面和其他已包裝物件的介面。如果介面與其他包裝函式的介面相同，則物件會有相同的識別，而且現有的包裝函式會傳遞給方法。
如果介面不是來自已知的物件，封送處理器會執行下列動作：
封送處理器會查詢 IProvideClassInfo2 介面的物件。如果有的話，封送處理器會使用從 IProvideClassInfo2.GetGUID 傳回的 CLSID 來識別提供介面的 Coclass。如果先前已經註冊組件的話，封送處理器就可以使用 CLSID 從登錄中找出包裝函式。
封送處理器會查詢 IProvideClassInfo 介面的介面。如果有的話，封送處理器會使用從 IProvideClassInfo.GetClassinfo 傳回的 ITypeInfo 來決定公開介面的類別之 CLSID。封送處理器可以使用 CLSID 來找出包裝函式的中繼資料 (Metadata)。
如果封送處理器仍然無法識別類別的話，它會以泛用包裝函式類別 (Wrapper Class)，稱為 System.__ComObject，來包裝介面。
請參閱
概念
Blittable 和非 Blittable 型別
方向屬性
複製和 Pin