All managed objects other
than those derived from ServicedComponent, when exposed to COM, behave as if
they have aggregated the free threaded marshaler (FTM). In other words,
they can be called on any thread without any cross-apartment
managed objects act as if they aggregate the FTM, they don’t actually
aggregate it because that would be inefficient. Instead, the CLR
implements IMarshal on behalf of all managed objects that don’t provide their
own implementation. The IMarshal implementation we provide is similar to
the one the FTM would do.
If a managed
object implements its own IMarshal, it should be aware of a quirk of OLE32 on
some versions of the operating system.
The IStream argument passed by OLE when calling your IMarshal interface
is sometimes allocated on the stack. So you better be done with that IStream
before you return to OLE. Of course
you are done with it, but the COM
Interop layer might hold onto it until a garbage collection recovers it. To avoid the subsequent heap corruption
and crash, you should explicitly call ReleaseComObject on the IStream argument
Obviously you are better
off allowing the CLR to implement IMarshal on your behalf!
The exception to all this
free-threaded behavior is any type that inherits from
System.EnterpriseServices.ServicedComponent. The runtime treats such
objects as if they really were unmanaged COM objects. All calls from
managed clients to ServicedComponent servers will check the apartment and COM+
context. If these don't match, the runtime pipes the call through COM so
that any thread marshaling or context transitions are correctly
this is a special section of the type hierarchy. And the fact that such types obey COM
rules is more of an implementation detail than it is a design point. All other managed objects are available
directly from all COM apartments and COM+
and COM apartments are completely orthogonal.