.NETアプリケーションのCOM Interoptで最も一般的な問題は、恐らくデプロイメントとバージョニングであろう。開発者は現在、「Primary Interopt Assemblies」を入れなければならず、Officeのようなアプリケーションの場合は1メガバイト以上になる。.NET 4では、この問題はなくなる。
COMの型埋め込みにより、インターフェースの断片を必要とするアッセンブリに、こうした断片をコンパイルすることが可能になる。プログラムが実際に使うインターフェースとメソッドのみが組み入れられるため、アプリケーションの全体サイズが劇的に減少する。
VTableを正確に保つために、アッセンブリのILにプレースホルダーとしてgapコマンドを入れる。gapコマンドは、スキップするメソッドスロット数を指し示す。発行済みのインターフェースでは、メソッドの場所変更をCOMが許可しないため、上位バージョニングと下位バージョニングの両方のサポートが可能になる。
これによって対処できるもう1つの問題は、より新しいバージョンに対するアプリケーションのコンパイルであり、たとえばエンドユーザーがWord 2003を使っている場合のWord 2007である。あるメソッドがランタイムバージョンに実際に存在するか否かは、ユーザーコードを使ってチェックしなければならず、さもなければアクセス違反が起こるだろう。しかし、下位互換性のあるメソッドのみを使う限り、他の問題は発生しないはずである。
使用を制御するのはコンパイラフラグになる。古いプロジェクトではデフォルトでオフになり、新しいプロジェクトではデフォルトでオンになる。めったに起こらないが、COMの型埋め込みが一定のCOMインターフェースで機能しない場合は、コンパイラエラーが起こってフラグをオフにするよう勧められるだろう。
関連機能としてType Equivalence（型の同値）とManaged Type Embedding（マネージド型の埋め込み）の2つがある。この2つにより、別アッセンブリの型をランタイム時に同型として扱えるようになる。複数のライブラリが同一のCOMインターフェースを読み込んでいるシナリオで不可欠である。これには厳密な規則がある。まず、すべての型をマッチアップできるように、共有GUIDでタグ付けしなければならない。COMではどちらにしろタグ付けされるため、問題にはならないが、マネージド型にはきちんと適用しなければならない。
標準クラスは実装が異なる可能性があるため、Type EmbeddingとType Equivalenceを介して共有できない。共有可能な型にはインターフェース、列挙、デレゲート、単純構造がある。
これまで述べてきた機能はVBとC#向けに計画されている。C++/CLIを使う開発者は通常、ヘッダーファイルを介してCOMオブジェクトにアクセスするが、現在のところMicrosoftはこの機能の提供を計画していない。