別の一連のカスタムコントロール（CustomButtons）を含むカスタムコントロールCustomContainerがあります。
したがって、コントロールCustomContainerには5つのCustomButtonがあります。
各CustomButtonsには、CustomContainerのコンストラクターに接続されているClickイベントハンドラーがあります。
これらのCustomButtonsイベントハンドラーの配線を解除するには、コントロールCustomContainerのオーバーライドDispose（UserControlから継承するためDisposeがあります）を作成する必要がありますか？標準の廃棄で十分ですか、それともここでメモリリークが発生しますか？
ありがとう、A。
いいえ、お持ちのイベントハンドラーからのサブスクリプション解除のためだけIDisposableに実装および実装する必要はありません。あなたが持っているそのイベントハンドラーの存在（投稿によると、ボタンのクリック）はメモリリークを引き起こしません。Dispose()
制御イベントを含むほとんどの場合、イベントの発行者とサブスクライバーは通常ほぼ同時に範囲外になるため、イベントを破棄せずに放棄して問題が発生することはありません。いくつかの点で、これは残念なことです。なぜなら、イベントのクリーンアップが正確さのために必要であると考えられた場合、おそらくそれに対する言語サポートがあり、適切に記述されたコードは当然のことながらイベントをクリーンアップするからです。
問題は、放棄されたイベントパブリッシャーがガベージコレクションされないようにするものはすべて、そのサブスクライバーがガベージコレクションされないようにすることです。それらのサブスクライバーが独自のイベントを公開すると、すべてのサブスクライバーも同様にガベージコレクションなどから不必要に保護されます。たとえば、1つが美しく機能するプログラムを持っているが、フォームに通知するイベントを追加するとします。別のフォームを開いたり閉じたりすると、各フォームに他の開いているフォームを一覧表示する「Windows」メニューを表示できます。素晴らしい機能。ただし、そのような通知を提供するイベントの購読を解除せずにフォームが破棄された場合、そのような失敗により、フォーム、そのコントロール、またはそれらが参照するその他のオブジェクトが収集されなくなる可能性があります。重大なメモリリーク、
フォームのDisposedイベントを使用してイベントのクリーンアップを処理することをお勧めします。Dispose設計者が生成したコードを変更することもできます。設計者はそれらの変更をそのままにしておくでしょうが、Disposedイベントが存在することを考えると、設計者が生成したファイルをいじくり回さないようにする方がクリーンだと思います。
IDisposableは、管理されていないリソースをクリーンアップするために使用されます。すべての管理対象リソースは、ガベージコレクターによってクリーンアップされます。オブジェクトへの参照がなくなると、次にGCを実行すると、アプリケーションからアクセスできないものがすべて解放されます。