最近、アプリケーションが解放されないメモリを消費しているように見えることに気付きました。CLRProfilerでプロファイリングした後、使用しているCastleWindsorコンテナーがオブジェクトを保持していることがわかりました。これらのオブジェクトは、構成xmlのlifestyle="transient"属性で宣言されます。
に明示的な呼び出しをIWindsorContainer.Release(hangingObject)行うと、その参照が削除されることがわかりました。
これは問題を引き起こしていますが、一時的なライフスタイルオブジェクトでCastleWindsorが参照を保持し、効果的にリークを作成するとは思っていませんでした。すべての適切な場所に明示的なRelease呼び出しを挿入することは、かなり平凡でエラーが発生しやすいタスクになります。
この問題を見たことがありますか、それを回避する方法について何か提案はありますか？
ここでの答えには重要なポイントが欠けていると思います-この動作はリリースポリシーを介してすぐに構成可能です-ここの城プロジェクトサイトのドキュメントをチェックしてください。
多くのシナリオでは、特にホスティングアプリケーションの存続期間中コンテナが存在し、一時的なコンポーネントを実際に追跡する必要がない場合（呼び出し元のコードまたはサービスで注入されたコンポーネントで廃棄を処理しているため）、リリースポリシーをNoTrackingReleasePolicy実装に設定するだけで、それを実行できます。
Castle v 1.0より前では、コンポーネントの負担が実装/導入されると思います。これは、注入された依存関係の破棄などに関するこれらの問題の一部を軽減するのに役立ちます。
編集：
コンポーネントの負担の詳細については、次の投稿を確認してください。
また、コンポーネントの負担は、WindsorContainerの公式2.0リリースで実装されています。
注意すべきことの 1 つは、これがキャッスル トランクで修正されたように見えることです。r5475 で、Hammett は MicroKernel のデフォルトのリリース ポリシーを に変更しましたLifecycledComponentsReleasePolicy。
コンテナー内のオブジェクトに対して、シングルトンまたはトランジェントのライフスタイルを設定できます。私が理解しているシングルトンオブジェクトは、アプリケーションの寿命を延ばす必要がありますが、この動作が一時的なものと同じであることの有用性を理解していません!
を実装することで、自分だけのライフスタイルを作ることができますILifestyleManager。ReallyTransientこれを適当に実装してライフスタイル型を作るのもありかも！