Do you need to remove an event handler in the destructor?

Question

I use some UserControls which get created and destroyed within my application during runtime (by creating and closing subwindows with these controls inside).
It

Answer 1

There are some cases where unsubscribing from an event in a Finalizer/destructor could be useful, if the event publisher guaranteed that unsubscription was thread-safe. For an object to unsubscribe from its own events would be useless, but one could as a workable pattern have a public-facing object hold a reference to a private object that actually "does all the work", and have that private object subscribe to events. If there is no reference from the private object back to the public object, the public object will become eligible for finalization once nobody is still interested in it; its finalizer would then be able to cancel the subscription on behalf of the private object.

Unfortunately, this pattern can only work if the objects whose events are subscribed guarantees that it can accept unsubscription requests from any threading context, and not just the context where events were subscribed. Having .NET require as part of the "event" contract that all unsubscribe methods must be thread-safe would not have imposed a major burden on implementations, but for whatever reasons MS did not impose such a requirement. Consequently, even if a Finalizer/destructor discovers that an event should be unsubscribed as soon as possible, there is no standard mechanism by which it can make that happen.