問題タブ [comvisible]

COM で表示できるようにしようとしている次のインターフェイスがあります。タイプ ライブラリを生成しようとすると、実装クラスがジェネリック クラスから派生するという事実が気に入りません。

ジェネリック クラスを COM 実装クラスとして使用することはできますか? (非ジェネリック ラッパーを作成して COM にエクスポートできることはわかっていますが、これにより、なくしたい別のレイヤーが追加されます。)

エラーメッセージ：

VS2005を使用して単純なC＃DLL（これははるかに大きなプロジェクトの一部です）を作成しました。VBAコードを介してExcelでDLLを使用する必要があるため、アセンブリでCOM相互運用機能を使用しています。ビルドプロセスで必要なTLBファイルを自動的に生成するようにしようとしているので、コマンドラインに移動してビルドのたびにregasmを使用する必要はありません。

私の問題は、DLLは正常にコンパイルおよびビルドされますが、TLBファイルを生成しないことです。代わりに、タイトルのエラーが出力ボックスに出力されます。

VS2005->ビルド->出力->[ COM相互運用機能の登録]でプロジェクトのプロパティに移動して、TLBファイルをビルドする他のDLLを取得しました。また、AssemblyInfo.csに[assembly：ComVisible（true）]があります。

問題のあるDLLのソースと、リターンタイプとして参照するDLLの概要は次のとおりです。

これがSymbolTable.dllの要約です。これは、ProblemLibraryが使用する戻り型を保持します。

C++をC++/ CLIに変換していて、いくつかのマネージクラスをCOMオブジェクトとして公開したいと思います。C＃では簡単で、[ComVisible]の設定とインターフェイス（ComVisibleも）からの継承が機能しました。ただし、C ++ /CLIとしてビルドされたC++プロジェクトは、DllRegisterServerをエクスポートしません。

これがサンプルプロジェクトです（VS 2008のCLRコンソールアプリケーションプロジェクトから開始）。

output .exeでzippy32を実行すると、DllRegisterServerが見つからないというエラーが発生しました。私はいくつかの助けを求めてグーグルを試しましたが、成功しませんでした。

サードパーティ コンポーネントを使用するこの ComVisible クラス ライブラリに取り組んでいます。このコンポーネントには、構成ファイルにいくつかの設定を追加する必要があります。私の dll を使用するアプリケーションは VB 6 アプリケーションであるため、どこに配置すればよいかわかりません。設定ファイル？実行時に構成ファイルをロードできる方法はありますか?

.NET クラスを COM に公開したいと考えています。それはかなり簡単です：

• ComVisible にする必要があるそのクラスのメンバーを定義するインターフェイスを作成します。
• これらのメンバーの DispId を自分で定義します
• インターフェイスはComVisible
• Guidそのインターフェイスに を割り当てます
• そのインターフェースを実装するクラスを作成します

大きな問題ではない。これはすべて機能します。しかし、私の質問は次のとおりです。そのクラスには、COM にも公開したいイベントがいくつかあります。
これも大したことではありませんが、いくつかの例 (MS の ComInterop ツールによって生成された fi コード) を見ると、イベントが別のインターフェイスで宣言されていることがわかります。つまり、あるべきクラスはComVisible、2 つのインターフェースを実装します。

• 必要な通常のメソッドとプロパティを定義する 1 つのインターフェイスComVisible
• であるべきイベントを定義する別のインターフェースComVisible。

さて、私の質問は次のとおりです。なぜですか？この理由は何ですか？

イベントが別のインターフェイスで定義されているのはなぜですか?また、ComVisibleイベントが定義されるべきメソッドとプロパティを含むインターフェイスで定義されていないのはなぜComVisibleですか?

この背後にある理由は何ですか?

最近、基本的にクラスとヘルパーである .NET 2.0 バージョンの内部フレームワークを開発しました。

問題は、いくつかの .NET 1.1 サイトとアプリケーションがあり、それらからフレームワークを使用したいということです。.NET 1.1 で .NET 2.0 を呼び出せないことはわかっていますが、考えがあります。

ComVisible を使用して別の 2.0 プロジェクトを作成し、2.0 アセンブリの一部を参照する場合は、これらのクラスのみを参照する必要な関数を再作成し、.NET 1.1 でこの新しい ComVisible アセンブリを呼び出します。.NET 1.1 で 2.0 アセンブリを使用できますか?

これが基本的に機能する場合、.NET 1.1、Java Reflection などで使用できます。

それとも私は時間を無駄にしていますか？

次のアセンブリがある場合：

MyComVisibleApi：VBアプリで使用される.Netアセンブリ

MyReferencedAssembly：MyComVisibleApiによって参照される.Netアセンブリ

MyReferencedAssemblyの機能がVBアプリによって直接参照されない場合、ComVisibleである必要がありますか？

ありがとう！

Visual Studioで新しいC＃プロジェクトを作成すると、生成されたAssemblyInfo.csファイルには、アセンブリGUIDを指定する属性が含まれます。属性の上のコメントは、「このプロジェクトがCOMに公開されている場合」に使用されることを示しています。

COMに表示する必要のあるタイプがアセンブリに含まれていないため、アセンブリに。のマークを付けました[assembly: ComVisible(false)]。では、GUIDを指定する意味はありますか？

私の考えでは、答えは「いいえ」です。それでは、デフォルトのAssemblyInfo.csファイルに[assembly: ComVisible(false)]との両方が含まれているのはなぜ[assembly: Guid("...")]ですか。

編集：

回答を要約すると：

それらの間で、回答は、COM相互運用機能が使用されている場合にのみGUIDを指定する必要があることを説明しています。したがって、私の状況では、GUIDは必要ありません。

Sharptoothはさらに、個々のタイプ[assembly: ComVisible(false)]をオーバーライドできるため、COM相互運用機能を使用しないことを意味しないと説明しています。ComVisibleこのため、デフォルトのAssembyInfo.csには[assembly: ComVisible(false)]とGUIDの両方が含まれています。

私はVB6に見えるように管理したアセンブリを持っていて、それは機能しますが、VB5で同じことを達成するのに問題があります。

VB6の場合、アセンブリを作成し、COMで表示できるようにし、COMオブジェクトとして登録しました。アセンブリは、VB6の参照リストに表示され、正常に使用できます。オブジェクトブラウザには、アセンブリ内のメソッドも表示されます。アセンブリとそのTLBをVB5開発に使用される仮想ワークステーションにコピーし、Regasmを実行しました。

仮想W/SはWin2kであり、.NET Fx 3.5はなく、2.0だけであることに注意してください。

アセンブリはVB5で選択できる参照に表示されますが、アセンブリのメソッドはオブジェクトブラウザに表示されず、通常は使用できません。私が行っていない手順があるか、VB5がそのようなCOMオブジェクトの使用方法を認識していません。VB5のセットアップは、VB6がインストールされているのと同じワークステーションではなく、仮想ワークステーション上にあることに注意してください。

何か案は？私が思いついたのは、問題のワークステーションで厳密な名前を生成して使用する必要があるかもしれないということですが...

他の .NET アプリケーションを介して COM 可視 .NET クラスを使用しようとすると、例外が発生します:

メッセージ: オブジェクトの型は __ComObject であるか、__ComObject から派生している必要があります。

パラメータ名: o

スタック トレース: System.Runtime.InteropServices.Marshal.ReleaseComObject (オブジェクト o) で

クラスは次のようになります。

コンポーネントを次のように登録します。

同じく .NET にあるクライアント アプリケーションは、指定されたクラスを正常にインスタンス化しますが、呼び出すMarshal.ReleaseComObject()と、上記の例外が発生します。

この問題を解決するためのアイデアはありますか?

編集: 残念ながら、オブジェクトをインスタンス化するためのクライアント アプリケーション コードを提供できません。ただし、クライアントが同じ方法を使用して実際の COM オブジェクトをインスタンス化していることはわかっています。