0

クライアント マシンで頻繁にリリース/登録する CodeDom を使用して COM オブジェクトを生成しています (VBA で使用するために C# から)。

これらのオブジェクトを生成しているので、固定 GUID を追跡するよりも、COM オブジェクトを更新/リリースするたびに、それぞれの新しいランダム GUID を取得する方が簡単であることがわかりました。

それは問題の潜在的な原因ですか？

4

2 に答える 2

1

パブリックメンバーが変更されたときにインターフェイスまたはクラスの[GUID]を変更することは、COMでは非常に難しい要件です。そうしないと、非常に厄介な種類のDLL地獄が呼び出され、クライアントは間違ったメソッドまたは存在しないメソッドを呼び出します。診断が非常に難しい。[GUID]を変更すると、クライアントコードがどこにも呼び出されない前にエラーが発生するようになります。

この特定のシナリオでは、[Guid]属性を使用せずに、CLRに任せて自動生成することをお勧めします。インターフェイスまたはクラスメンバーが変更されない限り、GUIDを安定させる非常に優れたアルゴリズムがあります。

初期バインディングを使用している場合は、GUIDを変更するには、クライアントコードも再コンパイルする必要があることに注意してください。一貫して行われたステップとしてそれについて言及しなかったので、クライアントコードが遅延バインディングを使用する可能性があります。VBAで行うのは非常に簡単ですが、実行時エラーではなく、コード補完やコンパイルエラーなどの快適さが失われます。遅延バインディングを使用する場合、[GUID]は重要ではありません。そのコードを確認してください。タイプライブラリが追加されていDimないAsか、追加されていない場合は、遅延バインディングを使用しています。

于 2012-12-04T14:42:02.910 に答える
1

変更されたすべてのcom-api-signatureの GUID を変更する必要があります。

@paulは、guidを変更するとバイナリ互換性が失われるということは正しいです。com に静的にリンクするすべてのクライアント (つまり、ac# クライアント) を再コンパイルする必要があります。

既存の com-api-signature を変更せずに新しい追加のメソッド シグネチャを作成する場合、クライアントの再コンパイルを最小限に抑えることはできません。

このようにして、古いプログラムは引き続き古い API を使用できますが、新しいプログラムは新しい API の恩恵を受けることができます。

于 2012-12-04T14:04:59.803 に答える