VSTO is COM object
Visual Studio Tools for Office (VSTO) add-ins are COM objects.
Almost every object that is used in Outlook is a COM object (inspectors, explorers, etc). They won't be discarded as long as any kind of reference is held on them. That means that when you are finished with these objects you must release your references to them. But you must also release the object from COM using Marshal.ReleaseComObject().
In many cases unless you do use Marshal.ReleaseComObject() you don't know when the objects are actually released and as a result you can get memory leaks.
You do have to be careful as to when you call Marshal.ReleaseComObject() because it releases all references to an object, including copies and different instances of the object. For example call Marshal.ReleaseComObject() on an Inspector passed to a class or method and not only that copy but the original object are released and attempts to use the object result in an invalid RCW error.
Only call Marshal.ReleaseComObject() when you are completely finished with an object and any copies/instances of the object.
Another reason to call Marshal.ReleaseComObject() is the default 256 RPC channel limit to Exchange. If you end up with that many or more current objects instantiated, for example in a loop, then you will get errors back when trying to instantiate any additional objects. That applies even to implicit objects internally instantiated due to dot operators. Setting the instances to null often isn't enough to release RPC channels due to the indeterminate nature of when the GC runs. In those cases often the only way to complete a loop is to explicitly call to Marshal.ReleaseComObject() and then to GC.Collect().
Almost every object that is used in Outlook is a COM object (inspectors, explorers, etc). They won't be discarded as long as any kind of reference is held on them. That means that when you are finished with these objects you must release your references to them. But you must also release the object from COM using Marshal.ReleaseComObject().
In many cases unless you do use Marshal.ReleaseComObject() you don't know when the objects are actually released and as a result you can get memory leaks.
You do have to be careful as to when you call Marshal.ReleaseComObject() because it releases all references to an object, including copies and different instances of the object. For example call Marshal.ReleaseComObject() on an Inspector passed to a class or method and not only that copy but the original object are released and attempts to use the object result in an invalid RCW error.
Only call Marshal.ReleaseComObject() when you are completely finished with an object and any copies/instances of the object.
Another reason to call Marshal.ReleaseComObject() is the default 256 RPC channel limit to Exchange. If you end up with that many or more current objects instantiated, for example in a loop, then you will get errors back when trying to instantiate any additional objects. That applies even to implicit objects internally instantiated due to dot operators. Setting the instances to null often isn't enough to release RPC channels due to the indeterminate nature of when the GC runs. In those cases often the only way to complete a loop is to explicitly call to Marshal.ReleaseComObject() and then to GC.Collect().
Comments
Post a Comment