Thanks for the pointers to the videos, Stephen. I had already watched the two you reference, but I got more out of the Memory profiling a real world application
videos. My question concerns my code which resembles the code shown in the LiveSqlWriter.Dispose() method shown around 1:28 into part 2
. Setting references to null, as the Dispose() method does (much like mine), might break part of the reference chain and removing event handlers might break more of it. But is setting references to null and unsubscribing to events all we can do?
My project has a main form that launches several child forms, much like the video but even uglier. Thanks to the VS.NET designer, this leaves tons of event handlers holding references to the child form that don't get cleaned up. If VS.NET is gracious enough to hook up events in InitializeComponent, why isn't there an UninitializeComponent that does the opposite? Using the object reference graph to determine whether an object is still "live" makes it seem like there absolutely has to be one. But there isn't, so I have to wonder why. If each object does not set each of its private fields to null, why isn't that a leak?