COM経由でC++クライアントにC＃タイプを公開することを検討しています。プロジェクトの人生にどんな問題がありますか？例えば。バージョン管理はどのように管理されますか？バージョン管理でC＃クライアントでC＃を公開する
、それは我々が[ClassInterface(ClassInterfaceType.None)]で露光することが私たちのタイプを飾ると、明示的なインタフェースを使用する必要がありますthisを読んだからと思われます。そうすれば、COMクライアントに公開されるインターフェイスを完全に制御することができます。
ありがとうございます。
C++クライアントを使用しているので、早期バインディングのために明示的なインターフェイスを使用する必要があります。ディスパッチインターフェイスは、VBSなどのスクリプトクライアントを使用する場合に便利ですが、C++クライアントにとってはほとんど役に立ちません。
インターフェイスをバージョンする唯一の方法は、新しいインターフェイスを作成することです（元のインターフェイスを継承する可能性があります）。明示的なインターフェイスを使用する場合は、このプロセスを完全に制御できます。
これは、COMを介して公開するすべてのクラスのインターフェイスを作成する必要があることを意味します。 ComVisible属性とGuid属性を持つすべてのインタフェースとクラスをマークすることを忘れないでください。また、すべてのクラスにはデフォルトコンストラクタが必要です。
バイナリ互換性を維持し、必要に応じてクライアントを再構築するために、GUID属性（including this）を読む必要があります。
ComVisible属性helps reduce registry pollutionにも興味があります。
COMインターフェイスを完全に制御するには、それらをMIDLで定義します。これらのインタフェースを持つタイプライブラリをC++プロジェクトに構築し、タイプライブラリをC＃にインポートしてインタフェースを実装します。
このアプローチは、マーシャリングが簡単ではない複雑なインターフェイスで役立ちます。
バージョンはCOMスタイルで行い、GUIDを変更し、新しいインターフェイスまたは継承するインターフェイスを追加する必要があります。
CoCreateInstanceでインスタンス化するクラスだけが、デフォルトのコンストラクタを持ち、COMに公開される必要があります。ファクトリメソッドだけが必要な場合は、インターフェイスを実装するクラスがCOM公開されていなくても、デフォルトのコンストラクタを持つ必要はありません。 – sharptooth
ファクトリメソッドはどこにありますか？ – ng5000
私は、これらのクラスに関係のないいくつかのインターフェイスを返す複数のファクトリメソッドまたは取得メソッドを持つ複数の公開クラスを持つことができます。これらのクラスは公開する必要がありますが、返されるインタフェースを実装するクラスでは必要ありません。 – sharptooth