Scott Hanselman

A good example of how this can come into play is if you have an old COM object and you use an interop from your managed code. Say you want to replace the COM object with a managed object. I don't want to get too far off track here but while you can make the managed code look like the old COM object via various COM attributes, you will run into problems if you run multiple AppDomains (NUnit, IIS) due to the managed client code to COM interop to managed server code path. A workaround for this is to gut the interop code, keeping the interface, name, and so on, and replacing the marshalling code with a direct call to the new managed component. Now you have managed client code that uses an "interop", which is really 100% managed, that then calls more managed code.

That all works unless your client code calls ReleaseComObject without checking IsComObject first. Since it isn't a COM object anymore you will get an InvalidCastException. Like Scott said, it's a good practice as it allows you to convert your legacy COM objects to managed code in the future with no client side code change.

I am amazed that ReleaseComObject is not a nop on everything not a COM object, or at least make that behaviour optional.

Do we really want to know via an exception that the operation is meaningless?

--
Thomas