私は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のようなロードコンテキストについてもう少し詳しく読んだが、正しいパスが取れているかどうかわからなかった。
何か案は？