1

.NET3.0と同じ方法で構築された2つのCOMDLLがあります。1つはデータベースからデータをフェッチし、もう1つはWebサービスからデータをフェッチします。

次のコマンドでRegAsm.exeを使用してDLLを常に登録しています。

cd "C:\Program Files\Dispatcher\COM\Custom" C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe MercatorRepositoryCOM.dll /tlb:MercatorRepositoryCOM.tlb /codebase C:\Windows\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe MercatorUtilitiesCOM.dll /tlb:MercatorUtilitiesCOM.tlb /codebase

これはほとんどのサーバーで機能します（Win2008R2 32b）

最新のサーバーでは、出力には次のように表示されます。正常に登録されました。ただし、アプリケーションはMercatorUtilitiesCOM.dllにアクセスできますが、MercatorRepositoryCOM.dllにはアクセスできません。

RegAsm、zippy32、regtlibv12を使用してDLLを登録し、さらにそれらをGACに追加してみました。何も機能しません。

「（10092）ActiveX自動化：サーバーはオブジェクトを作成できません。」よりもうまくトラブルシューティングできる方法はありますか？これらのDLLを登録する他の方法はありますか？

DLLコードにログを追加しようとしましたが、ログが書き込まれないため、DLLが呼び出されていないと想定できます。

PS：これらを参照する必要があるVB6に基づくスキャン/インデックス作成アプリケーションがあるため、これらをCOMDLLとして公開する以外に選択肢はありません。それはディスパッチャーです（それを知っているかもしれない人のために）。

更新：さらに調査したところ、DLLが正しく登録されているようです。登録を解除すると、DispatcherがDLL参照を見つけられないという明確なメッセージが表示されます。登録すると、Dispatcherが開き、ActiveXAutomationエラーがスローされます。したがって、DLLは正しく登録されているようですが、何らかの理由でDLL内でクラスをインスタンス化できません。

解決策：結局のところ、この問題はDLL登録とは関係ありませんでした。どうやら、Dispatcherを起動するアプリケーションにいくつかの内部変更があったようです。以前はサブプロセスを生成して同じapp.configを使用できるようにしましたが、別のプロセス（独自の実行可能ファイル）として実行するように変更しました。これは、app.configで構成とエンドポイントが見つからなかったことを意味します。新しい実行可能ファイル用に別のapp.configを作成し、それが機能します。ご協力ありがとうございます！

4

2 に答える 2

4

@WhozCraig が示唆したように、COM 登録とは関係のない他の問題が発生する可能性があります。これが真新しいテストサーバーで発生しているという事実は、インストールするのを忘れた他の依存関係があることを強く主張しています。これは、失敗したコンポーネントによって使用されますが、他のコンポーネントでは使用されません。2 つのアセンブリ参照を比較し、表示される違いを確認します。

別の簡単なテストは、 depends.exeを使用するか、 LoadLibraryを直接呼び出して、新しいテスト サーバーに dll をロードすることです。これはマネージ アセンブリであるため、何も生成されない場合がありますが、簡単に試すことができます。

次に、テスト サーバーでAssembly Binding Log Viewer (fuslogvw.exe) を実行して、アセンブリが他のアセンブリを参照しようとして失敗しているかどうかを確認します。基本的なアプローチは、ビューアーを実行し、[設定] をクリックして [バインドの失敗をディスクに記録する] に切り替え、必要に応じて既存のログをすべてクリアすることです。ここで、COM オブジェクトの読み込みに失敗したプログラムを実行し、失敗を再現して、ログ ビューアーのリストを更新します。新しいエントリが表示された場合、それが原因である可能性があります。

これらのエラーを診断するためによく使用する最後の最も強力なツールはprocmon です。これは、アプリケーションが動作していない COM DLL を読み込もうとしているときに、テスト サーバーで実行します。これにより、テスト サーバー上のプログラムによって実行されているすべてのファイル、レジストリ、およびネットワーク アクセスが表示されるので、おそらくフィルタリングを使用して、DLL をロードするプログラムからの出力のみを表示します。一般に、探しているのは、ファイルが見つからないかアクセスが拒否されたために失敗したファイルまたはレジストリ アクセスです。おそらく、実際には問題ではないファイルが見つからないエラーが多数表示されますが、アプリケーションがエラーを報告する前に表示される最後のエラーに細心の注意を払ってください。

次のように、アセンブリ自体に問題がある可能性もあります。

  • 実装クラスが非公開であるか、ComVisibleではない
  • 実装クラスには、パブリックの既定のコンストラクターがありません
  • アセンブリ内の静的コンストラクターが例外をスローしています
  • 実装クラスのインスタンス コンストラクターが例外をスローしています

ここでは最初の 2 つは問題ではないと思いますが、クラスがテスト サーバー上のリソースにアクセスしようとして失敗したのではないでしょうか?

于 2012-10-11T13:28:21.253 に答える