Describes COM object management in .NET The rules of com specify that com objects are reference counted, when a com object is referenced, the count goes up, release the reference and the count goes down. When the reference count hits zero, the com object is freed. When you import a com object into .net, it creates a "managed" proxy class, this marshals calls between .net and com, this proxy class holds a reference to the com object. With .net, you do not have to explicitly release objects once you are done with them. Once an object "goes out of scope", or is no longer used, it will be cleaned up by the garbage collector at some later stage. The garbage collector is triggered based on the amount of .net memory in use; it has no way of tracking what resources a com object has allocated. Once you stop using the com object (managed proxy), it does not immediately release the underlying com object. As ISYS com objects can allocate a process to do some work, you do not want them to be allocated for longer than necessary. Especially if it's "allocated" just because it's waiting for .net to free it. There are two ways to address the issue; the first is to release the com objects when you are done with them. The second is to force the garbage collector to run. Releasing the com objects as you go provides the best performance. You release a com object by calling "System.Runtime.InteropServices.ReleaseComObject". This forces the managed proxy to release the underlying com object. The down side to this approach is you must be strict about releasing all com objects, missing even one can mean that resources are still allocated. The second approach is to force the garbage collector to run; this is done by "System.GC. Collect". This is a brute force approach, but ensures that all the objects will be correctly freed.
|