Why don't COM object use IDisposable in their CLR Callable Wrappers?
-
1not sure what exactly you mean... COM objects are very complicated and IDisposable implementation would depend on several aspects including on how you plan to use the COM object... so how would the framework implement/do this automagically ? – Yahia Sep 19 '11 at 07:27
-
what would that accomplish exaclty ? see the answer of Joe and the links in that answer please... – Yahia Sep 19 '11 at 07:58
-
Ideally it would call Marshal.FinalReleaseComObject so you wouldn't have to do so in a finally block. – Jonathan Allen Sep 19 '11 at 09:56
-
and that call has its own quirks see the links in the answer from Joe – Yahia Sep 19 '11 at 09:57
1 Answers
Presumably such an IDisposable
implementation would call Marshal.ReleaseComObject.
There are cases where calling Marshal.ReleaseComObject is a good idea, for example to get an Office application to quit after automation from a .NET client.
But as the documentation for Marshal.ReleaseComObject
states, it should not be used in the general case - and probably not at all for in-proc COM objects. Here's a blog post with some more detailed info.
Hence it would not have been a good idea to encourage people to use it by calling it from an IDisposable
implementation in the RCW.
However, what's interesting is that the Silverlight 4 AutomationFactory.CreateObject
method does return a dynamic object that is IDisposable
. And tests seem to show that this does in fact release the COM reference, though documentation is a bit sparse.
-
-
@Joe: why isn't it an excellent idea to just call [Marshal.AddRef](http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.marshal.addref.aspx) if they _wanted_ the COM object to stick around? Do we leak resources by default, that is entirely opposite to the idea of garbage collection _and_ reference counting. I feel i must be missing something here – sehe Sep 19 '11 at 08:00