Click here to Skip to main content
Click here to Skip to main content
Alternative Tip

Tagged as

Go to top

Proper Way of Releasing COM Objects in .NET

, 2 Aug 2011
Rate this:
Please Sign up or sign in to vote.
Please let me suggest that "FinalReleaseComObject" is not the way to go. If you write structured code, you should never need it. Strictly following Microsoft Patterns & Practices:1) Declare & instantiate COM objects at the last moment possible.2) ReleaseComObject(obj) for ALL...
Please let me suggest that "FinalReleaseComObject" is not the way to go. If you write structured code, you should never need it.
 
Strictly following Microsoft Patterns & Practices:
 
1) Declare & instantiate COM objects at the last moment possible.
2) ReleaseComObject(obj) for ALL objects, at the soonest moment possible.
3) Always ReleaseComObject in the opposite order of creation.
4) NEVER call GC.Collect() except when required for debugging.
 
All of these things are documented on MSDN. Upon following these simple rules, .NET will optimize garbage collection along the way, minimizing memory/garbage load, and improving your overall application performance.
 
WARNING:
GC.Collect will stop all .NET process in the OS to collect garbage. With each call to GC.Collect, you may promote garbage from Generation 0 to Generation 1 and then to Generation 2. Once your garbage reaches Generation 2, you must terminate your process to recover memory.
 
Finally, your code may require calling GC.Collect to get around leaky code. You can unknowingly leak hidden COM objects into garbage just by taking legitimate coding shortcuts. For example:
 
Imagine a COM function that does work, and returns a COM object.
 
(comClass.comObject) myCom.ProcessError(errorNumber);
 
Your code doesn't want the resulting object, it just wants to process the error:
 
myCom.ProcessError(5);
Marshal.ReleaseComObject(myCom);
 
The returned COM object is sent to .NET garbage, keeping a handle to myCom from garbage.

 
Until GC naturally occurs, myCom will not be fully released. This is why so many people need to force object destruction using FinalReleaseComObject() and GC.Collect(). Both are required for dirty Interop code.
 
A CLEAN version of this code:
 
Marshal.ReleaseComObject( myCom.ProcessError (5) ); //Release returned object
Marshal.ReleaseComObject( myCom);
 
There are many other shortcuts where you ignore items in collections, and when you follow certain COM objects chains where you can leak intermediate objects. Again, please refer to Microsoft Patterns and Practices.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Crooked path
Architect Intergraph Corporation
United States United States
I've spent the last 30 years building durable code for government, healthcare, and utility companies, from Fortran 4 to C#, on databases from pre-SQL ISAM ones to Oracle 11g, and on platforms from the VMS to Linux (not to exclude all common permutations by Microsoft). In my spare time, I teach classes on whole-system design principles from configuring SANS, programming switches, to advanced principles in C# for creating secure, durable code.

Comments and Discussions

 
GeneralCalling GC.Collect() is not a good idea. PinmemberPranit Kothari6-Nov-11 7:14 
GeneralRe: GC.Collect() should <i><b>never </b></i>be used in productio... PinmemberCrooked path7-Nov-11 3:27 
GeneralTrue... not an alternate, but once I clicked "submit", I fou... PinmemberCrooked path4-Aug-11 2:57 
GeneralThank you for the reply. Actually it is not quite an "alter... Pinmemberwmjordan3-Aug-11 15:28 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web04 | 2.8.140921.1 | Last Updated 2 Aug 2011
Article Copyright 2011 by Crooked path
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid