質問: Appdomainの問題 私はappdomainの問題を把握しようとしている最後の数日間、壁に頭を打っている。 私はプラグインを実行する小さなウィンドウサービスを作成しました。それが動作する方法は、各プラグインは、 "CreateInstanceAndUnwrap"を使用して独自の別個のappdomainにロードされるdllであり、appdomainへの参照を保持し、プラグインが完了すると、そのplugin.i用に作成されたappdomainをシャットダウンしますシャドウコピーを使用して、プラグインがフレームワークで実行されている間にプラグインを更新できるようにしています。私はフレームワークのコア機能を別個のDLLに入れ、別のappdomainでそのDLLを実行することに決めたとき、6ヶ月間完全に実行されました。今のところ動作しています: Windowsサービスが起動します。コアdllは、CreateInstanceAndUnwrapを使用してロードされ、実行されます。これは、独自の別個のappdomainsでプラグインを実行することになります (CreateInstanceandを使用して..) 私はアセンブリのためにいくつかの異なる場所があります: Bin Folder(WindowsサービスのBinには、サービスで使用されているDLLのみが保持されます) コアDLLフォルダ(コアdllはここにドロップされます) 参照フォルダ(任意の参照はここにドロップされます) プラグインフォルダ(プラグインはここにドロップされます) **各**のappdomainのonassemblyresolveハンドラに接続することによって、未確認のDLLを解決します。 つまり、dllはネットワーク経由でロードされる可能性があります。 今問題は、Windowsサービスが1日実行され、メモリが1.5Gの高さになったことです。 私はメモリのダンプを作成し、ロードされたモジュールは、1.5G全体の100MBしかないように思われるので、このメモリがどこに行くのか分かりません。 debugdiagの使用ヒープフラグメンテーションの警告が表示されましたが、どこで問題を診断するか分かりません。 通常、フレームワークが1日実行されると、100Mのようなものが消費されました。また、これはプラグインとは関係がありません。これは、以前のようにmemroyの使用法がノーマルになったフレームワークに変更をロールバックしたときのようなものです。 私はプラグインのためのappdomainsを作成するとき、私はアセンブリの解決があまり頻繁に呼ばれることを望んでそこにdllの大部分を持っているCOREとReferencesフォルダへのappdomainのbasePathとbinパスを切り替えます。 私はfusionログを見て、default、from、noneのようなロードコンテキストについてもう少し詳しく読んだが、正しいパスが取れているかどうかわからなかった。 何か案は?
回答: 私はこれを考える: > フレームワークのコア機能を > 別のDLLをまた、別のappdomainでそのDLLを実行します。 > 今のところうまくいきます: > > > > Windowsサービスが起動します。コアdllは、 > CreateInstanceAndUnwrapは順番に実行します。 > 独自の別個のappdomains(CreateInstanceand ..を使って)のプラグイン > > これに反しているかもしれません: From http://msdn.microsoft.com/en-us/library/3c4f1xde.aspx > タイプT1のオブジェクトのメソッドMに事前バインドされた呼び出しを行うと > そのメソッドはCreateInstanceAndUnwrapによって返され、そのメソッドは > アセンブリCの型T2のオブジェクトのメソッドへの初期バインド呼び出し > 現在のアセンブリまたはT1を含むアセンブリ以外の、 > アセンブリCが現在のアプリケーションドメインにロードされます。このローディング > T1.M()への初期バインドされた呼び出しが > DynamicMethod、またはその他の動的に生成されたコードで使用されます。もし > 現在のドメインは既定のドメインです。アセンブリCはアンロードできません > プロセスが終了するまで。 > > この場合、Reflectionを使用して「適切な」呼び出しを実行して、早期バインディングを排除することができます。