6

COM から見える単純な .NET プロジェクト (クラス ライブラリ) を作成しました。VB6で動く！

コードは次のようになります。

[ComVisible(true)]
[ClassInterface(ClassInterfaceType::AutoDual)]
public ref class MyObject
{
    // Some methods and values
}

アセンブリは適切に署名され (GAC にない場合は必要ありません)、登録されています ( regasm MyProject.dll /tlb /codebase)。

次に、TLB ファイルが私の VB6 プロジェクトで参照され、すべて問題ありません! クラスとその中のパブリック メソッドにアクセスできました。

インターネット上でClassInterfaceType::AutoDualは、このアセンブリを使用するアプリケーションが機能しなくなる可能性があるバージョン管理の問題が発生する可能性があるため、このアセンブリを使用することはお勧めできません。

しかし、私の場合、それは本当に問題なのでしょうか? このアセンブリは、VB6 プロジェクト (早期バインディング) でのみ使用されます。

すべての新しいリリースで、これらの手順 (署名、登録など) を元に戻します。このソリューションのバージョン管理の問題はありますか?

[GUID("...")]とにかく、いくつかの属性を書いてもらえますか?

GUID は Visual Studio によって自動的に生成されるため、クラスはコンパイルごとに同じ GUID ではありません。そうですか？

4

1 に答える 1

11

AutoDual を使用しない場合、VB6 の事前バインディングは機能しません。また、VB6 エディターではオートコンプリートが機能しなくなったため、実行時エラーの原因となる入力ミスのリスクが高くなります。VB6 プログラマーはこれに慣れている傾向があるため、これを主張することもできます。

確かに、それは危険です。COM サーバーを更新し、[Guid] を指定して更新しないという誤りを犯した場合、VB6 プログラムが実行時に完全に診断不能なエラーでクラッシュするという重大なリスクがあります。さらに悪いことに、まったくクラッシュしないのに、完全に間違ったメソッドを呼び出します。

.NET に [Guid] を自動生成させる場合 (強くお勧めします)、実行時にハード クラッシュは発生しませんが、「ActiveX コンポーネントはオブジェクトを作成できません」というエラーが発生します。どちらの方が少しは役に立ち、確かに危険性は低くなりますが、どこで問題を探すべきかについて、あなたやユーザーにほとんどガイダンスを与えません。

ComInterfaceType.InterfaceIsIDispatch を使用すると、VB6 プログラマはレイト バインディングを使用し、GetObject() を使用してオブジェクトを作成する必要があります。[Guid] はもはや重要ではなく、変更がそれほど急進的でない場合、既存の VB6 コードが引き続き COM サーバーを使用できる可能性が高くなります。たとえば、メソッドが追加の引数を取得した場合でも、爆撃します。より良い実行時エラーが発生します。そうでなければ、VB6 プログラマーがもちろん期待していなかったメソッドのロジックの変更に対する治療法ではありません。欠点は、メソッド呼び出しが大幅に遅くなることです。

于 2013-08-16T12:10:28.143 に答える