類別的預設封送處理
類別只能由 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，來包裝介面。