問題タブ [com-interop]

COM Interop と WebBrowser WPF コントロールを介して、JavaScript コードから C# コードにデータを返しています。Javascript で次のようなデータを正常に返しました。

これで、C# でオブジェクトの結果が次のようになります。

このComObjectにあるこの配列に含まれるJavaScript文字列を取得するにはどうすればよいですか?

PhilWilsonによる例外的な記事BuildandDeploy .NET COM Assemblyに従って、COMに公開される.NETアセンブリを作成しました。

また、.NETアセンブリがCOMに適切に登録されており、コンパイルされたCOMコードで問題なく呼び出すことができるという意味で、すべてが正常に機能します。

唯一の奇妙なことは、VB 6.0またはVBAを使用するときにCOMに公開された.NETアセンブリに対して開発するには、プログラマーが関連する.tlbファイルの正確なファイルの場所を「参照」する必要があります。その後はすべて正常に機能します。つまり、クラスライブラリは[参照]ダイアログボックスに直接表示されないため、ファイルの場所を参照する必要があります。

繰り返しますが、COM相互運用機能の側面は100％機能します。ただし、VB6.0およびVBAの[参照]ダイアログ内でライブラリを直接表示できる設定が必要だと思います。

この設定がどうなるか誰か知っていますか？それとも、登録するだけで自動的に発生するのでしょうか？

アドバイスをよろしくお願いします...

マイク

編集/更新

/ codebaseスイッチを使用しているかどうかに関するjpohの質問に答えるために、RegAsmを明示的に使用するのではなく、.msiセットアップパッケージを使用しています。アセンブリは正しく登録されています。これは、HKCR \ CLSID {myGUID} \ InprocServer32内で、「CodeBase」キーがアセンブリへのフルパスを正しく保持していることからわかります。コンパイルされたCOMコンポーネントは、このdllに対して問題なく実行されます。参照ダイアログボックスに表示されないのは、VB6.0またはVBAを使用して開発した場合のみです。したがって、正しいファイルの場所に「参照」する必要があります。その後、100％正常に動作します。

アップデート＃2

さらに調査したところ、クラスGUIDは正しく登録されていますが、私の.tlbファイルは登録されていないようです。なぜだかわかりません。.tlbファイルを登録すると、クラスの基になっているインターフェイスのレジストリエントリがHKCR \ Interface {myInterfaceGUID}に配置されますが、これは発生しません。不思議なことに、この登録の欠如は、VB6およびVBAの参照ダイアログ内での検出可能性を除いて、dllの機能に影響を与えていないようです。

セットアッププロジェクト内の.tlbファイルのプロパティは正しいようです。「PackageAs」プロパティは「vsdpaDefault」に設定され、「Register」プロパティは「vsdrfCOM」に設定されています。なぜこれがターゲットマシンに正常にインストールされないのか、私は戸惑っています。

アップデート＃3

「ビルドが成功しました」と報告されているにもかかわらず、セットアッププロジェクトが正常にビルドされていないことがわかりました。

実際には、「ファイル名'DotNetLibrary3.tlb'の登録情報を作成できません」というビルド警告（驚くべきことに、エラーではなく警告）が報告されています。これは警告であり、エラーではないため、コンパイルは「ビルドが成功しました」と表示し、エラーリストは開きませんでした。

これを追跡すると、ここで説明するように、Vistaが開発マシンであるときにセットアッププロジェクトを作成しようとすると、これが問題になる可能性があります。

VS2008セットアッププロジェクトでのCOMtypelib登録の問題

ここで説明されているやや手動の修正があります：

フィードバック：「filename」という名前のファイルの登録情報を作成できません

私はまだ修正を試していませんが、明日、これで解決した場合は報告します。

アップデート＃4

それはあまりうまくいきませんでした...その記事で提案されているようにRegCap.exeを実行すると、Vistaで実行すると機能しないようです。RegCapは、実際には.msiの作成時にセットアッププロジェクト自体によって内部的に実行されるため、これはそれほど驚くべきことではありません。つまり、セットアッププロジェクトは、呼び出していたRegCapコマンドが失敗したため、ほぼ確実に失敗していました...したがって、RegCapを直接呼び出すことは役に立ちません。

肝心なのは、これはVistaでセットアップパッケージを作成しようとしたときの単なるバグであるということです。または、おそらくVisual Studio 2008とVistaの組み合わせかどうかはわかりませんが、同じ正確なアプローチを試みることは、WindowsXPで実行されているVisualStudio 2005でセットアッププロジェクトを作成することであり、まったく問題はありませんでした。

VistaやVisualStudio2008でこれを正しく実行するための修正があるかもしれませんが、追跡できませんでした。私にとってはるかに効率的なのは、WindowsXPでVisualStudio 2005を使用してビルドし、COM登録要件を生成してから、それらをVisualStudio2008セットアッププロジェクトにインポートすることでした。これらは、dllに対して/ regfileスイッチを使用し、.tlbファイルに対してRegCap（W'XPで実行！）を使用して、regasmを介して.REGファイルとしてエクスポートできます。私のCOMインターフェースは変更されないので、これを行う必要があるのは1回だけです。

うまくいけば、Vistaで実行しているときのVisual Studio 2008のこの問題は、ある時点で修正されるでしょうが、そうでない場合は、この投稿が同じ状況で自分自身を見つけた他の誰かにとって価値があることを願っています...

関連項目：

VB.NETで記述されたCOMServerforExcelをインストールしてAutomationServersリストに登録するにはどうすればよいですか？

-マイク

編集：言語/プラットフォームはC＃/ .Net

私は現在、現在のプロジェクトで膨大な単体テストの空白を埋めようとしていますが、TDDを初めて使用することは確かですが、ビジネスに不可欠な機能のテストを行う方法についてはかなり困惑しています。

私はMoqを手に取り、簡単なモックを作成するのに十分な時間を過ごしましたが、アプリケーションのコアにはかなり大きくて恐ろしいCOM相互運用レイヤーがあり、ユニットテストを適切に行う方法を概念化するのに苦労しています。COMコンポーネントは完全にサードパーティであるため、変更することはできず、電話を処理するための有限状態マシンに相当するものを実装します。コンポーネントは、状態の変化をシミュレートするために特定の順序でテストしたい一連の非仮想イベントを介してアプリケーションに通知しますが、Moqは仮想イベント以外に対してこれを行う方法を提供していません。

それで、より知識のあるTDDer / Mockistsへの私の質問は、この種のものをどのようにテストするのかということです。

どうやらTypeMockはこれをサポートしているようです（それ自体の欠点と引き換えに）が、型安全性と私の背後で何か悪意のあることをしているという私の一般的な感覚に関するさまざまな理由から、私はむしろそれを使用したくありません。

Windows サービス (services.msc でアクセス可能なバックグラウンド アプリ) アプリケーションを作成し、その中で ASP.NET WebService または Silverlight 互換の WebService をホストすることはできますか?

何かへの COM 相互運用呼び出しを実行する WebService を作成したいと考えており、COM と直接やり取りし、WebService をホストする Windows サービスが最も柔軟な方法であると判断しました。次に、ASP.NET Web サイトと Silverlight アプリケーションを作成して、WebService とやり取りします。

もう 1 つの方法は、サーバー側で ASP.NET に COM 相互運用呼び出しを実行させることですが、これはどれほど安全で、.NET はそれを許可しているのでしょうか?

IDL で次のような作成不可能なコクラスを宣言する理由は何ですか?

とにかく、そのようなクラスはCOMに登録されないということです。IDL ファイルと、その IDL ファイルをコンパイルすることによって生成されるタイプ ライブラリでそれを言及する理由は何ですか?

CoCreateInstance は、指定されたクラス ID の COM サーバーを見つけ、その ID のオブジェクト インスタンスを作成し、そのオブジェクト インスタンスからインターフェイスを取得することを理解しています。CoGetClassObject() は、クラス ID の COM サーバーを見つけ、そのクラス ID のクラス ファクトリのインスタンスを作成し、実際のオブジェクトの作成に使用できるクラス ファクトリ インターフェイスを取得します。

同じマシン上でオブジェクトを作成するために使用される場合、これらの関数は他にどのように異なりますか? それらは同じように動作しますが、まったく同じ COM サーバーで異なるコードが呼び出されるだけですか?

CoLoadLibrary() の説明には、LoadLibraryEx() とほとんど同じことを行うと書かれています - プロセスに DLL をロードします。COM クラス作成関数 (CoCreateInstance() と CoGetClassObject()) はどちらも、必要な DLL をプロセスにロードします。

では、そもそもなぜ CoLoadLibrary() が必要で、どのように使用する必要があるのでしょうか?

null BSTR (null WCHAR* ポインター) を空の文字列として扱い、それに応じて BSTR を操作するすべてのコードを設計することは、少なくとも一般的な方法です。この質問に対する答えは同じです。

このプラクティスはどこに文書化されていますか? この規則を説明する公式文書はありますか?

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が使用する戻り型を保持します。