Static Events Used By Static Classes

[Mike]

I am using a static event from the .NET framework and MSDN says:

"Because this is a static event, you must detach your event handlers
when your application is disposed, or memory leaks will result."

But I am using the event in a static class in a DLL so I can not
implement the disposable interface. Where should I detach the event?

Thanks,
Mike

 

[Kevin Spencer]

Hard to know without knowing what sort of application you're working with.
If it's a Windows Forms application, you can write an event handler for the
System.Windows.Forms.Application.ThreadExit or
System.Windows.Forms.Application.ApplicationExit events.

--
HTH,

Kevin Spencer
Chicken Salad Surgeon
Microsoft MVP

 

[Marc Gravell]

Where is that quotation from? If talking about individual objects, then it
makes sense - since otherwise the static event subscription will prevent the
object from being collected (causing memory to grow, or at least not be
reclaimed). However, long-lived subscriptions will happily die when the
process (exe, etc) dies; at which point all the memory is reclaimed.

If you can post a link to the offending MSDN page, I might be able to give
more info...

Marc

 

[Mike]

This is used in a DLL. That DLL might be used by a Windows Forms app
but that is not gauranteed.

 

[Mike]

It is from the SystemEvents.TimeChanged event.

http://msdn2.microsoft.com/en-us/library/microsoft.win32.systemevents.timechanged.aspx

 

[Marc Gravell]

I've had a quick dig, and the unsubscribe is only doing standard delegate
operations - nothing fancy (unmanaged handles etc). As such, you don't need
to worry about anything here if you are just subscribing a static method to
a static event - it will get cleaned up happily when the process dies.

Static events only normally become an issue when you are listening to them
from instances, i.e.

public class Foo {
public Foo() {
SomeStaticClass.SomeEvent += this.SomeInstanceMethod; // risky
}
// ...
}

because with the above (if not correctly released) the static event can keep
many, many objects alive accidentally. You don't have this problem if you
have a static subscription:

public static class Bar {
static Bar() {
SomeStaticClass.SomeEvent += Bar.SomeStaticMethod; // fine
}
// ...
}

Marc

 

[Kevin Spencer]

Hi Mike,

In that case, you can implement a Dispose method and a Finalizer. The
Dispose method can do the clean-up, and if it is not used by the developer,
the Finalizer can call it conditionally. The Finalizer is always called when
the DLL is unloaded from memory. See the following MSDN article on how to
implement this pattern:

http://msdn2.microsoft.com/en-us/library/b1yfkh5e.aspx

--
HTH,

Kevin Spencer
Chicken Salad Surgeon
Microsoft MVP

 

[Ben Voigt [C++ MVP]]

Where is that quotation from? If talking about individual objects, then it
makes sense - since otherwise the static event subscription will prevent
the object from being collected (causing memory to grow, or at least not
be reclaimed). However, long-lived subscriptions will happily die when the
process (exe, etc) dies; at which point all the memory is reclaimed.

What about AppDomain unload, where the hosting process might be very
long-lived indeed?