How To Destroy References To SolidWorks From Managed Code

December 20, 2007

 

Memory management in the COM world is a lot more straightforward in the COM world than it is in the .NET world.  Destroying COM references from .NET applications typically includes trial and error, calls to mysterious APIs, prayer and in the end, frustration.  It always reminds me of tying to kill a vampire, werewolf or some other bloodsucking, mythical creature that just won’t die.  It is because of this that my heart warmed with joy when I saw that some kind soul over at SolidWorks wrote a post to once and for all clarify how to destroy references to SolidWorks’  COM objects.

Tech Tip From SolidWorks On Destroying References To Unmanaged (i.e. COM) Components

 We have all heard about the promised land of .NET where you don’t have to worry about memory management.  The garbage collector handles all of the memory management for you.  You just instantiate your objects, use them and then forget them.  Santa Clause The .NET Garbage Collector determines when the objects are no longer needed and then destroys them and reallocates the memory.  Anyone who does API programming with SolidWorks in .NET either knows or should know that this is not the case for unmanaged (i.e.  COM) components (e.g. the SolidWorks class library used for interfacing with SolidWorks).  Some CAD systems (e.g. Unigraphics) have implemented a .NET API interface but SolidWorks still uses a COM  API interface.  This means that SolidWorks API developers using .NET must destroy SolidWorks objects “they d@mn self.” 

And remember…

…Even a man who is pure in heart
and says his prayers by night
may become a wolf when the wolfbane blooms
and the autumn moon is bright.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Posted by Jeff Cope | Filed Under .NET, SolidWorks API 

Comments

Got something to say?