問題タブ [registration-free-com]

インプロセス COM オブジェクトをアウトプロセス COM オブジェクトに変更しようとしています。新しいプロセスは Dispatch を以前に使用した COM オブジェクトに渡すだけなので、必要に応じてインプロセス オブジェクトに戻ることができます。これは正常に機能していますが、イベントに関する問題が発生しています。アウトプロセス サーバーは、以前に使用された COM オブジェクトのイベントをインターセプトし、これらを独自のイベント インターフェイスに渡します。このイベント インターフェイスも機能しています。しかし問題は、アウトプロセス サーバーが Windows レジストリに登録されていない場合、クライアントが DispEventAdvise を使用してこのイベント インターフェイスに接続できないことです。

サーバー IDL は次のようになります。

クライアントとサーバーに control_i.c、control_p.c、および dlldata.c を追加しました。そして、どちらも次の手順を実行してプロキシ/スタブを登録します。

これは、CoCreateInstance を使用して作成されるコントロールに対しては機能しますが、イベントに対しては機能しません。DispEventAdvise が CONNECT_E_CANNOTCONNECT を返し続けるため、シンクの DIID__IControlEvents の QueryInterface が E_NOINTERFACE を返します。

レジストリ内にコントロールを登録せずに、これを機能させる必要があります。また、マニフェスト ファイルと個別のプロキシ/スタブ DLL を使用して登録しようとしましたが、成功しませんでした。

この質問は、たとえばhereおよびhereなどの SO で以前に尋ねられました。シナリオは、マシンに COM コンポーネントを登録せずに、アプリケーションで COM コンポーネントを使用したいというものです。これは、2 つのマニフェスト ファイルを 1 つをクライアントに、もう 1 つをサーバーに追加することで実現され、残りは OS のサイド バイ サイド機能が処理します。すべてのDLLが同じフォルダにある場合、これは正常に機能するようになりました。

私の特定のシナリオでは、従来の .net 2.0 dll から 4.0 dll にアクセスしようとしています。2.0 dll を変更したくないので、上記の方法でこれを達成できました。ただし、4.0 dll が実行可能ファイル (2.0 dll) のサブフォルダーにある場合。サイド バイ サイド実行が開始されると、4.0 dll が見つかりません。現在、win32 API を呼び出して、マニフェスト ファイルを渡す新しい ActivationContext を作成しています。ProcMon を使用したところ、dll が検索用のマニフェストで指定されたパスではなく、実行可能ディレクトリで検索されていることがわかりました。上記のリンクも証明しているように、.net はマニフェスト内の ClrClass のみを認識しており、プライベート アセンブリ ルックアップ用に提供された AssemblyLocation を無視しているようです。

とにかく、上記のリンクの回避策はGACとAssemblyResolveです。可能であればGACを通過したくありません.4.0 dllをロードできない2.0 dllでサブスクライブする必要があるため、AssemblyResolveは機能しません。

アプリケーションが一時的に別の場所にあると考えて、dllが見つかるようにするハックの種類はありますか?

また、4.0 アプリを呼び出す 2.0 アプリを有効にするサービス (Web、Windows) の使用も認識しています。上記の 3 つ以外の他の可能性は高く評価されます。

私は、MS Access データベースに接続し、そこに格納されているデータベース オブジェクトの一部を使用できるようにする必要がある C# アプリケーションに取り組んでいます。

後で Access 関連のコードに小さな変更を加える必要があるかもしれない一部の人々は、主に VBA と DAO に精通しているため、(Microsoft.Office.Interop.Access.Dao PIA 経由で) ACEDAO.dll を使用することにしました。構文をできるだけ親しみやすくするためです。

上記の PIA を参照すると、必要な Access 固有の型を Visual Studio 2015 で簡単に使用でき、アプリケーションは完全に適切にコンパイルされます。ただし、デバッグプロセスを開始すると、すぐに例外が発生します。

Office 2013 をインストールしていますが、参照されている DLL (ACEDAO.DLL) が登録されていないようです。Microsoft から Access Runtime をダウンロードしてインストールするだけで、これを修正できました。その後、対応する .dll が登録され、アプリケーションが正常に動作します。

問題は、Access ランタイムのインストールに管理者権限が必要であることです。これは、クライアント PC にとって現実的なオプションではありません。アプリケーションを実行する必要があるすべての PC には、私の開発者マシンと同じバージョンの Office がインストールされており、ACEDAO.dll はプログラム ファイルの中にありますが、登録されていません... このライブラリを登録せずに使用することは可能ですか? ?

Office のインストール フォルダーにある ACEDAO.dll を参照すると、"isolated" プロパティを true に設定できました。これにより、ビルド時にかなりの数の警告が表示されましたが (COM 参照 'Microsoft.Office.Interop.Access.Dao' を分離する問題...)、バイナリ フォルダーに dll をコンパイルしてコピーし、マニフェストを作成しましたが、それでも動作しません。ライブラリが登録されていなくても機能します (mscorlib.dll からの ecxception 0x8007013D、メッセージ テキストがありません)...

ACEDAO ライブラリをターゲット マシンに登録せずに使用できるかどうか、およびどのように使用できるかについて何か考えはありますか?

マニフェスト ファイルを生成した COM Interop を介して公開される C# .NET DLL があります。DLL は、オブジェクトを作成するために Excel VBAProject を使用して消費されてCreateActCtxいCreateObjectます。

すべて正常に動作しますがregasm MyProject.dll /codebase、GAC に電話または登録する必要があります。そうしないと、ActiveX component can't create objectまたはerror in dllエラーが発生します。

DLL をまったく登録せずに .NET DLL を使用することは可能ですか? 以前は、VB6 ベースの DLL とマニフェスト ファイルを使用してこれを行うことができました。

C# を使用して、.Net Framework で登録不要の COM オブジェクトを作成する必要があります。

MSDN ウォークスルーに従いました。または、私には十分に明確ではないか、正しくないため、私はそれに取り組む必要がありますが、これは古い投稿であり、Windows 10 で Visual Studio 2015 を使用しているため、何かが変更されている可能性があります。

以下に、それを機能させるために行った手順を示します。

1. COM C# dll SideBySide.dll(Target Framework 2.0) をコンパイルします。もちろん、regasm で登録していません。

2. チュートリアルで説明されているアプローチは使用していません。うまくいかないようです。で作成SideBySide.Manifestしますmt.exe。コマンドは次のとおりです。

   mt -outputresource:"<path SidebySide.dll>" -manifest "<SideBySide.manifest>"

3. 生成されたマニフェストを手動で変更して、役に立たないタグをすべて削除し、必須のタグを追加しました。変更されたマニフェストは次のとおりです。

4. SideBySide.dll次のコマンドでマニフェストを追加しました。

   mt -outputresource:"<Path SidebySide.dll>" -manifest "SideBySide.manifest"

5. SideBySide.dll using tlbexp`から TLB をエクスポートしました。

6. C++ クライアントの構成でNoを設定しました。Properties -> Manifest tool -> Embed Manifest

7. をコンパイルclient.exeし、client.exe.manifestファイルに変更を適用しました。変更されたマニフェストは次のとおりです。

すべてがうまく機能しており、ネイティブ C++ アプリケーションから .Net Framework COM インターフェイスを使用できるようです。

SideBySide.dllただし、 .Net Framework 4.0 以降でコンパイルしようとすると、次の呼び出し時に問題が発生しますCreateInstance。

このエラーが発生します:

0x8013101b : このアセンブリは、現在読み込まれているランタイムよりも新しいランタイムによってビルドされているため、読み込むことができません。

もちろん、上記のすべての手順を実行しようとしましたが、DLL のマニフェストでランタイム バージョンも指定しようとしましたが、役に立ちませんでした。

この投稿も読みました。問題は同じですが、ネイティブ クライアントから C# COM オブジェクトを呼び出す必要があるため、私の意見では、解決策は私には適していません。

適用する回避策はありますか、それとも問題に対して別のアプローチが必要ですか?

マニフェスト、特に MSBuild タスクの GenerateApplicationManifest を使用して、メイン アプリケーションが Isolated COM を使用できるようにしました。クライアント マシンに DLL を登録しなくても、必要な DLL に実装されたすべての COM オブジェクトを作成できます。でも、私は貪欲です...

私たちのアプリケーション スイートには、通常、COM を介して呼び出される個別のアプリケーションもいくつかあります。これらについては、EXE to EXE 分離 COM はできないと言われています。厳密に言えば、それは本当ですが、私は 90% の道のりをたどりました。他のフォーラムでは、他の人が残りの道をたどる手がかりを与えているのを見てきました。

私の EXE サーバーの場合、マニフェストに EXE サーバーの名前のエントリとそのエントリのサブエントリがあり、ATL サーバーが を呼び出したときLoadRegTypeLib()に呼び出しが成功するようにしています。それはうまくいきます。

もちろん、難しいのは、クライアント アプリケーション マニフェストに EXE サーバーのエントリを配置して、CoCreateInstance()(サーバー EXE を起動し、COM が行う他のすべてのことを実行することによって) 成功することを期待できないことです。

どのEXEサーバーを起動するかを知っているので、かなりの偽物を作ることができます。クライアント アプリで呼び出しCreateProcess()てから呼び出しWaitForInputidle()て、クライアント アプリで CoCreateInstance() を使用できるようにサーバーを準備できます。

クライアントアプリでインターフェイスを呼び出しCoCreateInstance()てIDispatch要求すると、呼び出しは成功し、呼び出すことができInvoke()、すべてが機能します。

ここで貪欲な部分が来ます...

IDispatch が機能することはまったく問題ありませんが、IDispatch から派生したデュアル インターフェイスを介して呼び出すことができるようにしたいと考えています。そのように記述されたコードがたくさんあり、構文がより単純であり、例外処理が既に存在するため、それを行いたいと考えています。

ただし、QueryInterface()インターフェイスでデュアル インターフェイスを呼び出すとIDispatch、E_NOINTERFACE が返されます。サーバー EXE の ATL サーバー オブジェクトにブレークポイントを設定し、サーバー側でインターフェイスを見つけて S_OK を返すことを確認できます。そのため、どういうわけかインターフェイスをクライアントにマーシャリングすることができないようです。

問題は、QueryInterface()カスタム/デュアル インターフェイスを成功させるにはどうすればよいかということです。<comInterfaceProxyStub>クライアント マニフェスト (およびサーバー マニフェスト) で と を使用してさまざまな組み合わせ<comInterfaceExternalProxyStub>を試し、インターフェイスをマーシャリングしようとしましたが、クライアントにまだE_NOINTERFACE戻りが見られます。

数年前の別のフォーラムで、インターフェイスをマーシャリングするために別のプロキシ/スタブ DLL が必要になる可能性があるという Hans Passant のコメントを見ましたが、詳細はあまりありませんでした。

登録不要のコンテキストでこれを解決することさえ可能ですか? プロキシ/スタブ ライブラリを作成する必要はありますか? その場合、マニフェスト エントリはクライアント アプリケーション (および/またはサーバー アプリおよび/またはプロキシ/スタブ DLL) でどのように表示されますか?

C# サーバーから C++ クライアントへの COM イベントを処理しようとしています。サーバー regfree を使用できますが、イベントが機能しなくなりました。

IDispEventImpl以前は、登録により、イベントはATL からクライアントで処理されていました。

これに直接対処する記事を見つけることはできませんでしたIConnectionPointが、本質的に登録を必要としない提案を見ました.

IDispEventSimpleImplまた、 regfree で動作する可能性のある提案もいくつか見ました。