問題タブ [assembly-loading]

外部アセンブリのロードを自分で処理する必要がある環境で使用する DLL があります。アセンブリを AppDomain にロードしたいと考えています。CurrentAppDomain でこれを試すと問題なく動作しますが、自分で作成した appdomain でこれを実行すると失敗します。背景は、アセンブリが最後に「解放」されるように、最後に appdomain をアンロードしたいということです。

私の質問は、アセンブリをロードするために作成した appdomain をどのように使用するのですか?

プロジェクトのプラグイン .dll に実装されたクラスのインスタンスを作成して、型検出を行おうとしています。私はこの例外を受け取っています:

アセンブリ 'SquidReports.DataCollector.Plugin.BES、バージョン = 1.0.0.0、カルチャ = ニュートラル、PublicKeyToken = null' からタイプ 'Action' を読み込めませんでした。

これは私が使用している正確なメソッド シグネチャです: https://msdn.microsoft.com/en-us/library/d133hta4(v=vs.110).aspx

つまり、次のように、アセンブリ名とクラス名に基づいてオブジェクトを生成しようとしています。

ここで注意すべき重要な点は、アセンブリの「完全な」名前 (Version、Culture、PublicToken を含む) ではなく、「短い」名前を使用していることです。ただし、MSDN は明確に次のように述べています。

'assemblyName' は、次のいずれかになります。 パスまたはファイル拡張子を含まない、アセンブリの単純な名前。

• たとえば、パスと名前が .\bin\TypeExtensions.dll のアセンブリに TypeExtensions を指定します。

• 署名されたアセンブリの完全な名前。単純な名前、バージョン、カルチャ、および公開キー トークンで構成されます。たとえば、「TypeExtensions、Version=1.0.0.0、Culture=neutral、PublicKeyToken=181869f2f7435b51」などです。

具体的には、アセンブリ「SquidReports.DataCollector.Plugin.BES」で定義されたクラス「Action」のインスタンスを作成しようとしています。インスタンスを作成しようとしているのとまったく同じ *.cs ファイルの先頭で、このアセンブリをusingディレクティブとして明示的に参照しています。

以前の質問/回答から次の提案を試しました。

ソリューションを一掃し、再構築して再試行してください。これは一部の ASP.NET プロジェクトでは機能するようですが、これは単純な古いコンソール アプリです。

構成ファイルで参照されているアセンブリを確認してください 繰り返しますが、これは同じソリューションの異なるプロジェクトで GAC とライブラリのみを使用する単純なコンソール アプリです

1. アセンブリが正しい作業ディレクトリにあることを確認します。

ここにいる...

2.アセンブリがディスク上の同じバージョンであることを確認します

うん...

3. 最後の推奨事項は、fuslogvw.exe を使用することでした。

ツールを使用した経験はありませんが、奇妙なことが 1 つあります。デバッグ セッションを実行すると、アセンブリの長い名前と短い名前の両方のバージョンが表示されました。

両方のログを見ました。

短い名前のバージョンは、いくつかの警告を生成するようです:

=== プレバインド状態情報 ===

ログ: DisplayName = SquidReports.DataCollector.Plugin.BES Partial) WRN: アセンブリの部分バインディング情報が提供されました:

WRN: アセンブリ名: SquidReports.DataCollector.Plugin.BES | ドメイン ID: 1

WRN: アセンブリの表示名の一部のみを指定すると、部分バインドが発生します。

WRN: これにより、バインダーが不適切なアセンブリをロードする可能性があります。

WRN: アセンブリに完全に指定されたテキスト ID を提供することをお勧めします。

WRN: 単純な名前、バージョン、カルチャ、および公開キー トークンで構成されます。

WRN:この問題の詳細と一般的な解決策については、ホワイト ペーパーhttp://go.microsoft.com/fwlink/?LinkId=109270を参照してください。

...しかし、正常にロードされて終了し、アセンブリが正しい場所にあることを明確に示しています。

ログ: 新しい URL ファイルのダウンロードを試みています:///C:/Source/C#/SquidReports/SquidReports.DataCollector/bin/x86/Debug/SquidReports.DataCollector.Plugin.BES.DLL。

長い名前のバージョンのログには、疑わしいメッセージは含まれていません。

他にアイデアはありますか？

EDIT : Action クラスの最小限の定義を次に示します。純粋にモデルクラスです。

ICollectible インターフェイスと [Key] 属性は、さらに別のアセンブリの一部です。それが効果があるかどうかわからない？

編集 2: Erik が以下で指摘しているように、明らかに、この OTHER アセンブリでもまったく同じチェックを行いました。

コンソール アプリまたは Windows サービスとして実行できる .NET アプリケーションがあります (起動パラメーターによって異なります)。

ここでの考え方は、インスタンスをコンソール アプリとして実行し、同じマシン上でサービスとして実行されている別のインスタンスの UI として機能させることです。つまり、インスタンス #1 は、インスタンス #2 の状態を調べて制御できます。両方のインスタンスが同じ物理ファイルから実行されます。アプリケーションのインストールは 1 つだけです。

たとえば、WCF サービス レイヤーを作成せずに (アクセスする必要があるメソッドがたくさんあります)、アプリへの最小限の変更でこれを達成する必要があるため、コンソール アプリが直接コードを取得できるかどうか疑問に思っていました。 -サービス アプリ内の public static オブジェクトへのコード参照。

アクセスしたい public static オブジェクトは EXE 自体にありますが、必要に応じて、アプリによって読み込まれたアセンブリに移動できます。

廃止されたという事実を除けば、.NET Remoting が解決策のように思えます。別の可能性はありますか？

PowerShell を使用して、Akka.Net アクターを使用する F# コードを呼び出そうとしています。

F# コードは、単体テストおよび F# インタープリターから実行すると正常に動作しますが、PowerShell コマンドレットから同じコードを呼び出すと、次の例外が発生します。

その PowerShell セッションで実行[Nessos.FsPickler.BinarySerializer]::new.OverloadDefinitionsして、PS が使用可能なメソッドを確認したところ、次のようになりました。

私が最初に気付いたのは、PowerShell によって表示されるバージョンが FSharpOption[Boolean] の代わりに FSharpOption[bool] を取ることでした。Option を明示的に渡すように Akka.FSharp コードを変更しようとしましたが、それは役に立たなかったようです。

私は FSharp.Core 4.0.0.1 を使用しています (他のリンクでは 3.0 に問題があることが示唆されています)。

誰かが似たようなものを見たことがありますか？

問題を探す場所についての提案も役に立ちますが、問題が PowerShell、F#、または Akka.Net にあるのかどうかはわかりません。

Assembly Binding Log Viewer はかなりバグが多く (たとえば、多くの場合、ログが空になりません)、機能が不足しています (検索、順序付け、フィルタリングはほとんど利用できません)。

だから私はどちらかどうか疑問に思っていました

• 既存の代替案が存在する
• assemblyresolve イベントをグローバルにフックすることは何とか可能であるため、自分で行うことができます
• マイクロソフトはソースをどこかに公開しており、フォークすることが許可されています

2 番目のオプションを除けば、CLR ホストの実装を比較的簡単に作成できることはわかっていますが (自明ではありませんが)、既存の Fusion ログ ビューアーよりも細かい制御が必要な場合は、やり過ぎのように思えます。

この回答を見たことがありますが、この質問には回答していないようです。

いくつかのコメントへの回答:

アセンブリのリダイレクト、AssemblyResolveおよびAssemblyLoadイベントについては認識していますが、最初のイベントは最後の手段 (プローブ チェーンの最後) としてのみ使用でき、2 番目のイベントはアセンブリが読み込まれた後にのみ発生します。どちらも自分のプロセス以外で使用することはできず、プローブ プロセス全体を表示することもできません。

RyuJIT を使用すると、コンパイルされた IL をコンパイルおよびロードする方法が異なるため、一部のバインディングがわずかに異なる順序で表示されることに気付きました。fuslogvw.exe私は拘束力のある問題を調査して解決することができましたが、時間のかかる (親切で便利なツールの 1 つではありますが)ことを非常に嫌うようになりました。そのため、調査プロセスを監視するためのより良いツールを探すために (むしろ実りのない) 検索を開始しました。

私たちのアプリケーションはかなり最近の protobuf-net (バージョン 2.0.0.668) を使用しており、古いバージョンの protobuf-net (バージョン 1.0.0.282) を使用するクライアント ライブラリを持つ別のシステムに統合しようとしています。同じ Windows サービスでアセンブリ リゾルバーを使用してライブラリを並べて使用することは可能ですか? シリアライザーに関して、これらのバージョン間に重大な変更があること、およびバージョン間に個別の protobuf プロトコルの重大な変更があることを理解しています。

アセンブリ リゾルバー アプローチを使用しようとしたのは、アウト オブ プロセスに移行し、クライアント呼び出しごとに回線経由で呼び出しを行うことで、このクライアント ライブラリの呼び出しのオーバーヘッドを削減したかったからです。私はそれを並行して機能させたかったのです。

アセンブリ リゾルバーが配置されている場合でも (詳細は後述)。そして、新しいバージョンを取得するように見える古いprotobufを必要とするライブラリでAssembly.Loadを呼び出します。バインドされたリダイレクトがない場合でも。また、バインディング リダイレクトの自動生成を無効にするようにプロジェクト ファイルで具体的に指定しました。

バージョン 1.0.0.282 を使用するようにプロジェクトへの特定のバージョン参照を指定した場合でも、完全に分離されたプロジェクトが新しいバージョンの protobuf にデフォルト設定されるのはなぜですか? 最終結果は、protobuf.net のバージョン 1.0.0.282 バージョンを必要とするライブラリで protobuf メッセージを正常にシリアル化できないということです。

GAC を使用しないという制約があり、別のサービスで古いバージョンのクライアント ライブラリへの呼び出しをラップする別のサービスを作成しないという制約があり、プロセス外になることで非常に高価な呼び出しになります。

私のプロジェクト構造は次のとおりです

ソリューション |_WindowsService - DLL LibraryA および DLLLibraryB を参照 |_DLL_LibraryA - protobuf 2.0.0.668 および DLL_LibraryB を参照 |_DLL_LibraryB - protobuf 1.0.0.282 および DLL_ThirdpartyClient を参照

DLL_LibraryA および DLL_LibraryB プロジェクトは、特定のバージョンを使用し、ローカルにコピーしないように、protobuf.net への参照を使用してセットアップされます。

WindowsService プロジェクトでビルド イベントを作成し、appdomain resolveassembly イベントがトリガーされたときにアセンブリ ローダーによって検出されるように、bin->ThirdParty->protobuf-net->{version} フォルダー内の protobuf-net ファイルをファイル コピーしました。

アセンブリを完全に分離し、プロジェクト構成を設定してバインディング リダイレクトの自動生成を無効にしても (自動バインディング リダイレクトを無効にする)。私のアセンブリ ローダーは、バージョン 2.0.0.668 に対してのみ呼び出されます。

ただし、興味深い点の 1 つは、私たちのソリューションが合成と依存性注入に MEF を利用していることです。効果があるのか​​しらん。また、私のソリューションの構造に基づいて、DLL_LibraryA は protobuf-net 2.0.0.668 に依存し、間接的に DLL_LibraryB の依存関係を介して protobuf-net 1.0.0.282 に依存します。この場合、clr は何をしますか? プロセスから外れることなくこれを成功させる方法はありますか? CLR が常に最新バージョンをロードすることを決定したのは、依存関係が混在しているためですか?

どんな情報でも大歓迎です。

詳細はこちら：

1. バージョン リゾルバーを作成する - アセンブリ リゾルバーを使用する Side-by-Side アセンブリを使用して x64 または x32 バージョンの DLL をロードする

   /li>

2. Windows サービス プログラムでリゾルバーを呼び出す -

   static Program() { AppDomain.CurrentDomain.AssemblyResolve += VersionResolver; }

EntityFramework 5.0.0.0 に依存する Visual Studio 拡張機能を作成しています。プロジェクトに EntityFramework を含めました。拡張機能をインストールすると、拡張機能の DLL が VS 拡張機能フォルダーに表示され、EntityFramework.dll も表示されます。

ただし、Visual Studio 2013 (update 5) で拡張機能を実行すると、EntityFramework を読み込めません。System.IO.FileNotFoundException: Could not load file or assembly 'EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.

Process Monitor を見ると、拡張機能を実行すると、VS2013 が EntityFramework を別のパス (別のバージョン - 4.2) から読み込もうとすることがわかりました。VS2013 が引き続き EntityFramework を検索し、拡張機能に含まれる他の dll の場合と同様に、拡張機能のフォルダーでそれを見つけることを期待していますが、そうではありません。

VS2015 では、VS は EntityFramework 5.0.0.0 をロードできますが、別の別のパスからもロードします。

VS2013 が拡張機能のフォルダーで EntityFramework を検索し続けないのはなぜですか?

CSharpCodeProvider を使用してオンザフライでコードを生成およびコンパイルするアプリケーションがあります。コンパイルされるコードは Entityframework を使用するため、Entityframework.dll への参照をコンパイラに渡します。アプリケーションと共に再配布する Entityframework.dll は、.net 4.0 用に構築されたものです。また、System.ComponenModel.DataAnnotations.dll への参照をコンパイラに渡します。これは、GAC で見つかった dll への参照です。

.net 4.0 でアプリケーションを実行すると、これらすべてが正常に機能します。ただし、.net 4.0 の Entityframework にあった一部の属性が .net 4.5 の System.ComponenModel.DataAnnotations に移動されたため、.net 4.5 で実行すると問題が発生します。したがって、次のようなエラーが発生します。

メッセージ = エラー (CS0246): 型または名前空間名 'Column' が見つかりませんでした (using ディレクティブまたはアセンブリ参照がありませんか?) - ファイル: c:\Generated\DataContext\0rs2sztj.2.cs:14 エラー(CS0433): タイプ 'System.ComponentModel.DataAnnotations.Schema.ColumnAttribute' は両方の 'c:\Users\Steven Segers\AppData\Local\Temp\Temporary ASP.NET Files\vs\69fafaea\17b01629\assembly\dl3 に存在します\95fc97d4\5bdae37d_7c05d101\EntityFramework.DLL' および 'c:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.ComponentModel.DataAnnotations\v4.0_4.0.0.0__31bf3856ad364e35\System.ComponentModel.DataAnnotations.dll' - ファイル: c :\Generated\DataContext\0rs2sztj.2.cs:14

私が見る限り、これには2つの方法があります。

1. .net 4.0 の System.ComponenModel.DataAnnotations の参照アセンブリをコンパイラに渡します。ここでの問題は、この参照アセンブリがターゲット マシンに存在する必要があることです。これに対応するには、顧客にサーバーに Windows SDK をインストールするよう要求するか、参照アセンブリをアプリケーションと共に配布する必要があります。前者はかなり望ましくない要件だと思います。後者が許可されているかどうかはわかりません。
2. ランタイム .net バージョンを対象とする Entityframework.dll をコンパイラに渡すようにしてください。これを達成するための最良の方法が何であるかはわかりません。