問題タブ [idisposable]

これは、「C# 経由の CLR」、「効果的な C#」およびその他のリソースから IDisposable およびファイナライザーについて理解していることです。

• IDisposable は、マネージド リソースとアンマネージド リソースを確定的にクリーンアップするためのものです。
• アンマネージ リソース (ファイル ハンドルなど) を担当するクラスは、IDisposable を実装し、クライアント コードがインスタンスで Dispose() を呼び出さなくてもクリーンアップされることを保証するファイナライザーを提供する必要があります。
• 管理対象リソースのみを担当するクラスは、ファイナライザーを実装しないでください。
• ファイナライザーがある場合は、IDisposable を実装する必要があります (これにより、クライアント コードは正しいことを実行して Dispose() を呼び出すことができますが、ファイナライザーは忘れた場合のリソースのリークを防ぎます)。

上記のすべての理由を理解して同意しますが、これらのルールを破ることが理にかなっているシナリオが 1 つあります。それは、管理されていないリソース (特定のファイルへの単一アクセス ポイントを提供するなど) を担当するシングルトン クラスです。 ）。

シングルトンインスタンスはアプリケーションの存続期間中存続する必要があり、クライアントコードが Dispose() を呼び出すと、詰め込まれているため、シングルトンに Dispose() メソッドを持つことは常に間違っていると思います。ただし、アプリケーションがアンロードされたときにファイナライザーがアンマネージ リソースをクリーンアップできるように、ファイナライザーが必要です。

したがって、IDisposable を実装しないファイナライザーを備えたシングルトン クラスを持つことは、合理的なことのように思えますが、このタイプの設計は、私が理解しているベスト プラクティスに反しています。

これは合理的なアプローチですか？そうでない場合、その理由と、優れた代替手段は何ですか?

MVVM パターンを使用して Silverlight アプリに取り組んでいます。私のViewModelは現在、モデルオブジェクトのコレクションを表すプロパティで構成されています:

また、Web サービスから返されたデータをコレクションに取り込むメソッドもいくつかあります。

このクラスのインスタンスは、アプリケーションの実行時に作成および破棄される可能性があるためIDisposable、プロパティの参照を実装して null に設定する必要がありますか?それとも、このクラスの破棄は、プロパティが参照するコレクションへのすべての参照を削除するのに十分でしょうか? そこにぶら下がっている参照を残す可能性のある警告はありますか?

ありがとう。

IDisposableの実装方法に関するMSDNの記事を読んでいましたが、記事で引用されているマネージドリソースとネイティブリソースの違いについてはよくわかりません。

破棄するときに2つのフィールドを破棄する必要があるクラスがあります。それらをマネージド（破棄= trueの場合にのみ破棄）またはネイティブリソースとして扱う必要がありますか？

例えば：

各アイテムを明示的にデキューして個別に破棄しない場合、Clear() を呼び出したときに残りのアイテムは破棄されますか? キューがガベージ コレクションされるときはどうですか?

答えが「いいえ」であると仮定すると、ベストプラクティスは何ですか? 常にキューを反復処理して、各アイテムを破棄する必要がありますか?

特に、例外がスローされた場合に備えて、最後に各破棄を試行する必要がある場合は、醜くなる可能性があります。

編集

したがって、一般的なコレクションのユーザーには、アイテムが使い捨て可能 (ガベージ コレクターによってクリーンアップされないアンマネージド リソースを使用している可能性が高いことを意味します) の場合、次のことを知る負担があるようです。

1. コレクションから項目を削除するときは、必ず Dispose() してください。
2. Clear() を呼び出さないでください。コレクションを繰り返し処理し、各アイテムを破棄します。

おそらく、ジェネリック コレクションのドキュメントにそのことが記載されているはずです。

ASP.NET では、項目が IDisposable を実装するセッション状態のままであるが、セッションの有効期限が切れたときにアプリケーションによって明確に削除および破棄されない場合、Dispose() のコードが実行されるオブジェクトで Dispose が呼び出されますか?

私は次のようなコードを持っています。このコードは非常に頻繁に使用されます。

コードは今日は正常に機能しますが、サーバーへの接続はかなり長い間開いたままになります。（TCPViewを使用してチェック）

Close()メソッドを明示的に呼び出すことには利点がありますか？それは推奨されますか、それとも行わないことが推奨されますか、そしてその理由は何ですか？

C ++ / CLIIDisposableは、refクラスにデストラクタを実装するときに、スキャフォールディングを生成するのに役立ちます。また、デストラクタを実装していないが、クラスにを実装するメンバー変数があるIDisposable場合IDisposableは、クラスに再び自動的に実装されます。IDisposableこれは非常に便利で、C＃での処理方法よりもはるかに優れています。

msclr::com::ptr（RCWを含むスマートポインター）を保持するrefクラスを実装するときに、この動作に遭遇しました。

私の特定のケースでは、クラスによって参照されるCOMオブジェクトは、一部のアンマネージリソースを「ロック」せず、CLRが認識できないアンマネージメモリを事実上消費します。したがって、クラスを実装しないことで、refクラスのユーザーを混乱させないようにしたいと思いますIDisposable。代わりに、GC APIを使用して適切なメモリプレッシャーを追加することにより、CLRにCOMオブジェクトの存在を認識させたいと思います。

したがって、問題は次のとおりです。IDisposableデストラクタを実装していないが、IDisposableメンバー変数を保持しているrefクラスでの実装を抑制する方法はありますか？

注意：これは、クラスのユーザーが基になるCOMオブジェクトを決定論的に破棄できないため、間違ったことになることがよくありますが、特定の状況を考えると、公開するIDisposableと、refクラスのユーザーを混乱させる可能性があります。問題のrefクラスを破棄する必要はありません。

1つのオプションは、デストラクタなしでmsclr :: com::ptrのバリアントを実装することだと思います。

IDisposableの自動追加を抑制する他の方法をいただければ幸いです。ありがとう。

答え

_aComObjectmsclr :: com :: ptr（）へのハンドルとして宣言しmsclr::com::ptr<IWhatever>^ます。その場合、コンパイラはTestcom ptrオブジェクトの「所有者」であるとは見なさず、Testが削除されたときにそれを破棄しません。

いくつかの C# クラスをリファクタリングしているときに、IDisposable を実装するクラスに出くわしました。

何も考えずに、IDisposable インターフェイスを実装するクラスごとに部分クラス ファイルを作成しました。

例) Stamper.cs -> Stamper.cs + Stamper.Dispose.cs の場合、Stamper.csには実際のスタンピング ロジックが含まれ、 Stamper.Dispose.csには破棄ロジックが含まれます。

コードを見てみると、Stamper.cs はかなりすっきりして読みやすくなっています (約 50 行は単にクリーンアップの破棄コードであった 100 行ではなく、約 52 行になりました)。

私はこれで行き過ぎですか？

*EDIT : ご意見をお寄せいただきありがとうございます。2 つのファイルを 1 つにまとめることにしました。私が直面した問題は、実際のロジックを更新した後に IDisposable 実装を更新するのを実際に忘れていたことです。

さらに、ソース コード内のメソッド間を移動するのにそれほど問題はありませんでした。最初の理由は、私の特定のケースでは 1 つのファイル ソリューションに固執するのに十分な理由のようです。

オブジェクトを使用する（プライベートフィールドとして持つ）クラス（たとえばMyClass）がありTcpClientます。メソッドでの呼び出しをMyClass実装します。IDisposableTcpClient.CloseDispose

私の質問は、呼び出し元のコードによって呼び出されない場合に備えて、アンマネージ リソースを解放するMyClassために呼び出すファイナライザーも実装する必要がありますか?Dispose(bool Disposing)TcpClient’sMyClass.Dispose

ありがとう