私は、COM interopを通していくつかの.NET APIを公開する製品に取り組んでいます。ビルドの一部として、そのようなアセンブリすべての* .tlbファイルを生成し、別々のSDKパッケージの一部として提供します。当社の顧客は、当社製品の上にSDKをインストールし、当社のCOM APIを使用するアプリケーションを作成することができます。実行時に* .tlbファイルが使用されましたか？
これらの* .tlbファイルを製品自体に出荷して登録する必要がありますか？実行時に* .tlbが必要とされ、それらに対してコード化されたサードパーティのライブラリが実行される状況がありますか？
はいと答えた場合の動作を教えてください。私はインターネット上で、それを配信して登録しなければならないと言っている多くのコメントを見ましたが、なぜそれを行うべきかを明確に説明するものは見つかりませんでした。それは私にそれが本当であることを疑わせました。
はい、可能です。特に.NETの場合は、クライアントコードがどのようにサーバーを使用するのか予測できないため、型ライブラリの登録を省略しないでください。
彼らは特に一般的ではないが、2つのケースがあります。
クライアントコードは、あなたの[のComVisible]メソッドを呼び出すと、呼び出しがアパートの境界を越える
。アパートはCOMコンセプトであり、少しばかだとSTAとMTAの違いを理解する必要があります。シンプルに保つ：アパートの境界は、通話が別のスレッド、別のプロセスまたは別のマシンから行われたときに、通常は交差します。 COMは、コールの引数をIPCパケットにシリアル化する方法を理解するのに役立つ必要があり、引数の型を知る必要があります。 COMのReflectionという概念はないので、自動的には行えません。ほとんどの場合、IDLファイルから生成されるプロキシとスタブを実装する別個のDLLが必要です。これは.NETでは難しいことですが、Windowsに組み込まれた標準のマーシャラーを使用して、ほとんどの場合便利な第2の方法を使用します。どのタイプの型があるかを調べるためにタイプライブラリを使用します。 Regasm.exe/tlbオプションは、インターフェイスのプロキシ/スタブとタイプライブラリが登録されているので、標準のマーシャラがライブラリを見つけることができます。パブリックインターフェイスで構造体を公開すると、構造体は相互運用シナリオでは非常に面倒です。レイアウトにはコンパイラの設定に大きく依存しています。同等の.NETプロパティはStructLayout.Packです。 .NETでは8で修正されていますが、クライアントコードはそれを認識しません。構造体にアクセスするには、クライアントコードでIRecordInfoを使用する必要があります。構造体の各フィールドがメモリ内のどこにあるかを調べることができます。タイプライブラリは、IRecordInfoに必要な情報を提供します。確かに、.NETで完全に、非常に簡単に構造体を避けるのが最善です。
COMコンポーネントで.tlb参照として使用していた.Net dllを登録する際に問題が発生しました。
.Net dll（.tlbプロジェクト）を登録する必要はありません。
私はうまくいきたいと思います。
ありがとうございました。私が探していただきありがとうございました。 – Dennis
Microsoftのドキュメントで確認済み： http://msdn.microsoft.com/en-us/library/eaw10et3.aspx#marshaling_and_com_apartments "クロスアパートメントマーシャリングのオーバーヘッドを受け入れます。これは、コールが多い場合に顕著です境界を越えてアパートメントの境界を正常に通過するためには、COMコンポーネントのタイプライブラリを登録する必要があります。 " – Dennis
http://msdn.microsoft.com/en-us/library/windows/desktop/ms692621(v=vs.85）aspx "カスタムインターフェイスのプロキシとスタブを生成するためにMIDLを使用する代わりに、タイプライブラリを生成することができ、システムが提供するタイプライブラリ駆動のマーシャリングエンジンがインターフェイスをマーシャリングします。 – Dennis