I love reading posts like this from Sam Gentile. (Though I am timid about writing about them, as I’m always worried I’m gonna get something wrong! 🙂 ) But these posts are where you can really see his expertise through the experience he has had in drilling into very complex and detailed areas. I think my “vast” [read sarcasm there] experience with COM Interop is not much more than managing a bunch of dynamically called activex controls and maybe a bitmap here and there. Nothing that creates the real issues of dealing with COM resources in a managed environment. For the “lay” .NET developer (as in layman, layperson), the GC is something to just let it do it’s thing. My guess is your average VB6 –> .NET developer is not that aware of the GC much less worried about the types of issues that Sam points out. (And hopefully they aren’t working on anything where NOT knowing is a big detriment to anyone.) Then there are probably the C++ –> .NET developers that are working on the type of projects where, truly, the GC is able to handle everything, but they just can’t let go of that nagging feeling that they must hand code every release of objects and memory. But on the large scale .NET apps that are growing out of large scale COM apps, this is definitely not a light weight issue.

I’ve played with the new GC Memory Pressure functions in whidbey/vs2005 and wondered if they would be enough for people doing the types of projects that Sam is working on or satifsfying enough for people with the level of knowledge that he has. It was interesting for me, then to see that Sam says that yes, it is a huge step, but still the problem remains, what to do today?.

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!