問題タブ [assembly-loading]

Outlook アドインで発生する非常に奇妙なアセンブリ参照の問題と読み込みの問題があります。詳細は次のとおりです（長い話:)）：

.Net 1.1 を使用して記述およびビルドされた古い Outlook アドインがあります。アドインは、独自のアプリケーション ドメインで管理されていない shim を使用して読み込まれます。ユーザーのマシンに 1.1 が存在しなくても、.Net 2.0 で問題なく動作します。

このアドインは、Outlook 2000 に対して VS 2003 によって作成されたカスタム Outlook 相互運用機能アセンブリを使用し、その後再構築して厳密な名前を付けます (私のアドインのように)。

アドイン プロジェクトでは、このカスタム相互運用アセンブリのみを参照し、公式の MS 相互運用アセンブリへの参照はありません。

このアドインを Outlook 2007 と .Net 2.0 の環境で使用すると、公式の MS 相互運用機能アセンブリが GAC にインストールされているため、何らかの理由で、アドインがそれらを読み込んで使用することがわかります。

Connect クラスのコードには、using ディレクティブがあります。

これは、カスタム相互運用アセンブリの名前空間です。

Connect ctor には、次のコード行があります (テスト目的で追加されました)。

これは以下を出力します:

Outlook.Application の完全な種類: Outlook.ApplicationClass、Interop.Outlook、Version=9.0.0.0、Culture=neutral、PublicKeyToken=4cfbdc5349cf59d8

これはまさに私が期待したものです。

問題は、OnConnection(object application, Extensibility.ext_ConnectMode connectMode, object addInInst, ref System.Array custom) が呼び出されると、ログに表示されることです (現在のドメインの AssemblyLoad イベントへのフックがあります)。アセンブリもロードされます:

出力：

アセンブリ Microsoft.Office.Interop.Outlook、Version=12.0.0.0、Culture=neutral、PublicKeyToken=71e9bce111e9429c のロード元: GAC

私の OnConnection メソッドは次のように始まります。

これは以下を出力します:

OnConnection アプリケーション オブジェクトの完全な型は、Microsoft.Office.Interop.Outlook.ApplicationClass、Microsoft.Office.Interop.Outlook、Version=12.0.0.0、Culture=neutral、PublicKeyToken=71e9bce111e9429c です。

次の行で Outlook.Application に問題なくキャストできることがわかるので、これは非常に奇妙です。

Reflector で確認しましたが、アセンブリは Microsoft の相互運用アセンブリをまったく参照していません。私の Interop.Outlook.dll についても同じです。

それで、誰かが何が起こっているのか知っていますか？これらの質問に対する答えは何ですか:

1. Microsoft アセンブリをロードするのはなぜですか?

2. 異なるアセンブリで定義された、無関係なクラス/インターフェイス間でキャストするにはどうすればよいですか?

注: 新しいアドインを作成しました。これは非常に単純なもので、何もせず、ロードするだけです。私は問題を再現できたので、CLRがどの相互運用機能をどこからロードするかをどのように決定するかを知っている人はいますか? GAC以外に、COMオブジェクトとそれが必要とする相互運用の間にリンクがある別の場所(レジストリ???)はありますか?

私はmsdnのドキュメントを見ていましたが、アセンブリを使用する場合LoadFileとLoadFromロードする場合の正確な違いについてまだ少し混乱しています。誰かがそれをよりよく説明するための例または類推を提供できますか. MSDN のドキュメントは、私をさらに混乱させました。また、反射モードでのみアセンブリをロードすることを除いてReflectionOnlyLoadFrom、 と同じです。LoadFrom

私の .NET の経験はあまりよくないので、LoadFile を使用した MSDN ドキュメントに関するいくつかの質問を以下に示します。

LoadFile1)同じ ID を持つが、異なるパスにあるアセンブリを調べるとはどういう意味ですか? 正体（例）は？

2) はLoadFileファイルを「LoadFrom コンテキスト」にロードせず、ロード パスを使用して依存関係を解決しないと述べています。これはどういう意味ですか、誰かが例を提供できますか?

3) 最後に、LoadFileLoadFrom は ID が同じでパスが異なるアセンブリを読み込めないため、この限定されたシナリオで役立つと述べています。最初のそのようなアセンブリのみをロードするため、同じ質問が再び発生します。アセンブリのアイデンティティは何ですか?

.net1.1から.net3.5への移行の一環として、いくつかのベンダーDLLを変更する必要がありました。

そのうちの1つは、私たちが使用している4つのスポットのうち1つのスポットだけで問題を引き起こしています。

問題のある場所は、リフレクションを使用して、長時間実行されるプロセスを実行するいくつかのDLLを動的にロードするWindowsフォームプロジェクトです。これらの長時間実行されるプロセスの1つは、ベンダーDLLの1つに依存するエージェントです。

ライブラリを参照する関数を最初に入力した時点で、欠落しているアセンブリ例外が発生しています。参照を古いバージョンから新しいバージョンに移動するのを忘れたかどうかなど、私はすでに愚かなことをチェックしましたが、そうではありません。プロジェクトのbinディレクトリも確認しましたが、アセンブリはそこにあります。

.net 2.0ランタイムがそのようなアセンブリのロードを拒否する状況に遭遇した人はいますか？もしそうなら、どうすれば問題を解決できますか。

追加情報：

この場合の特定のベンダーはdtSearchであり、これはエラーがスローされる境界です。

ライブラリはSetIndexOptionsで参照されます。BuildIndex()入力されますが、SetIndexOptionsが呼び出されると例外が発生します。関数が実際に入力されることはありません。

実行時にメモリ（バイト配列）からクラスがロードされて「実行」されるJavaアプリケーションを移植しています。C＃で同じことを達成しようとしていSystem.IO.FileNotFoundExceptionますが、バイト配列からアセンブリをロードしようとすると（AppDomain.Loadメソッドを使用して）問題（例外）が発生します。

このバイト配列をファイルシステムに永続化する必要なしにそれらをロードする方法はありますか？

アイデアを単純化するために、コードを動的に実行および変更（更新）する機能が必要です。アセンブリを「ロード/アンロード」するために、個別のアプリケーションドメインを使用します。

MEFが、アプリケーションフレームワークがとるべき適切な方向であるかどうかを判断しようとしています。MEFを読んだところ、私たちのフレームワークは「正確に」適合していないようですが、専門家が私を導いてくれるかどうかを確認します。

私たちのフレームワークでは、1つのコアWebサイトと依存アセンブリを1つの場所にデプロイでき（修正または機能はすべてのクライアントに伝達されます）、コアWebサイトに「マージ」して必要に応じて拡張するクライアントWebサイトがあります。

現在IISでは、各クライアントサイトは、独自のAppDomainで実行される独自のアプリケーションです。ただし、すべてのアプリケーションには、「コアWebサイト」を指す同じ物理パスがあります。

したがって、ファイル構造は...

• / CoreSite
  • / bin（コアサイトと依存関係のdllを含む）
  • / [コアサイトフォルダ]（例：モデル、ビュー、コントローラ、コンテンツなど）
  • /クライアント
    • / _Assemblies（すべてのクライアントアセンブリを含む-数百のクライアント）
    • / Client1
      • / [クライアントサイトフォルダー]（モデル、ビュー、コントローラーなど）
    • / Client2
      • / [クライアントサイトフォルダー]（モデル、ビュー、コントローラーなど）
    • / ClientN

ご想像のとおり、アセンブリのロードが問題です。いくつかの理由から、すべてのクライアントアセンブリをルート/binフォルダーに配置したくありませんでした。まず、各クライアントサイトに他のすべてのクライアントアセンブリをロードさせたくありませんでした。次に、別のクライアントのアセンブリが/ binフォルダーで更新されたという理由だけで、すべてのサイトのAppDomainがリサイクルされることを望んでいませんでした。

これをasp.net1.1で機能させるために、http： //www.hanselman.com/blog/MovingTheCodeBehindAssembliesDLLsToADifferentFolderThanBINWithASPNET11.aspxに従い、web.configに<probing privatePath = "bin; Clients /_Assemblies"/>要素を追加しました。クライアントサイトの各ビューに<％@ Assembly Name = "ClientN"％>ディレクティブを使用します。克服しなければならなかった他の唯一の問題はクライアントアセンブリの更新でしたが、asp.net1.1は/Clients/_Assembliesディレクトリ内のアセンブリをロックしていました。単に追加しました：

そしてビオラ、すべてが魅力のように機能しているように見えました。残念ながら、asp.net 4.0では、AppDomain.CurrentDomain.SetShadowCopyPath（）は非推奨になりました。そのため、バイト配列からアセンブリを自分でロードしようとしたり、AssemblyResolveイベントを使用したり、[アセンブリ：PreApplicationStartMethod（typeof（MvcApplication）、 "PreApplicationStart"）]をいじったり、Systemを使用したりしました。 Replication.BuildManager.AddReferencedAssemblyは役に立ちません。

次のいずれかを取得します。-アセンブリがロードされていない-アセンブリが多すぎる、または-アセンブリがロードされているが、ビューがレンダリングされているときに、名前空間が<％@ Assembly Name="ClientN"から配置されているはずの<Import/>ディレクティブに遭遇した場合％>は単に失敗します。

だから私は、MEFが進むべき道であるかどうかについてのメカニズムやアドバイスを使った提案を求めています。私の1000フィートの見方では、MEFは、複数のコンポーネントがプラグインされている1つのアプリケーション（またはWebサイト）を対象としています。私たちの状況では、アプリケーション/アプリドメインごとに一度に1つのコンポーネントしかプラグインできないため、メジャーコードリファクタリングを開始することを躊躇しています（そう思われます）。また、必要以上のことを実行しているようです（アセンブリをロードして、asp.netに認識させるだけで、すべてのコードが機能します）。

アドバイスをいただければ幸いです。

どちらを使用する場合の影響と推奨シナリオは何ですか？

新しいプラグインベースのアプリを書いています。これにより、アセンブリが独自のアプリドメインに読み込まれ、Application.Run（pluginForm）を介して各ドメイン内に指定されたメインフォームが表示されます。アプリドメイン内でApplication.Run（pluginForm）を呼び出す前に、ローダーアプリのメインフォームを各pluginFormの親として設定しました。したがって、pluginFormが表示されると、ローダーアプリのmainFormの前に常に表示されます。

私の問題は、ユーザーがpluginForm（子フォーム）を初めてクリックすると、フォーカスが失われ、mainForm（ローダーアプリのフォーム）がフォーカスを取得することです。（ただし、pluginFormは前面にとどまります）したがって、ユーザーは、pluginFormを初めてフォーカスするために、2回クリックする必要があります。

これはかなり迷惑です。どうすればこれを修正できますか？

プラグインシステムでは、オブジェクトをインスタンス化し、識別子（単に文字列）を持ついくつかの着信要求に基づいてそれらのオブジェクトのメソッドを呼び出します。構成の助けを借りて、この識別子は、ロードするアセンブリ、インスタンス化するこのアセンブリのクラス、および呼び出すメソッドを決定します。アセンブリは別のAppDomainにロードされます。これは、次のように作成されたプロキシクラスで発生します。

SecondDomainProxyクラスで、identifier上記に関連するアセンブリをロードします。

質問：アセンブリがロードされたら、このAssemblyオブジェクトへの参照を保持することは意味がありますか？たとえば、辞書を使って...

...そして上記のコードを次のように変更します：

Assembly.LoadFromを最初に呼び出した後、AppDomainがアンロードされるまで、アセンブリがロードされることを認識しています。（私の場合、2番目のAppDomainはメインアプリケーションと同じくらい存続します。）つまり、Assembly.LoadFromへの2回目の呼び出しは、辞書検索と同じくらい安い、安い、またはほぼ同じくらい安いということですか？または、assembly.LoadFromを呼び出さず、代わりに保存された参照を使用するという欠点がありますか？

（私が持っていない高いパフォーマンス要件がない限り、それは実際には問題ではないと感じています（およそ15秒ごとに1つの要求）。しかし、私は間違っている可能性があります。）

事前にフィードバックをありがとうございます！

編集：

Assembly「通常の」.NETクラスです。このクラスのインスタンスへの参照がない場合は、ガベージコレクションが行われると思います。ただし、アセンブリ自体はロードされたままです。したがってAssembly.LoadFrom、少なくともAssemblyクラスの新しいインスタンスを作成する必要がありますが、2回目は、このインスタンスの作成は、すでにロードされているアセンブリに基づいている可能性があります。

質問を追加したいと思います。特定のアセンブリのアセンブリオブジェクトを作成するには、かなりの反射が必要であるため、アセンブリがロードされているかどうかに関係なく、常にコストがかかりますか？

実行時にアセンブリをコンパイルしてロードする方法を見つけようとしています。基本的な意図は、それらをディスクではなくデータベースに保存することです。そこで、いくつかのコードを書きましたが、興味深い状況が見られました。これが私のコードです：

コードは削除行がコメントアウトされている状態で完全に実行されます。コメントを外すと、アプリケーション ドメインがアセンブリをロードし、AssemblyLoadEvent()メソッドが実行され、コンソールに 9 が表示されますが、メソッドが終了apd.Load()するとエラーがスローされます:「ロードできませんでした」ファイルまたはアセンブリ。」これは完全に合理的です。

AssemblyLoadEvent()問題は、ディスク上のアセンブリ ファイルなしでメソッドを実行するにはどうすればよいかということです。

メソッドが生のバイナリ データの助けを借りて何らかの方法で実行される場合、appdomain がLoad()メソッドを正常に終了させる方法はありますか?