[Mono-devel-list] COM Interop
monoman at gmail.com
Mon Jul 25 13:29:37 EDT 2005
On 7/25/05, Jonathan S. Chambers <Jonathan.Chambers at ansys.com> wrote:
> I am interested in implementing some support for COM Interop for
> the mono runtime. A goal is that the mono version of COM Interop could
> support various component models (COM, XPCOM, and Bonobo have been
> proposed); whether more than one can be supported at one time is another
> decision that someone will need to make.
I would hope that not to happen, as COM is just more trouble than it
is worth. I prefer to rewrite any COM component as something fully
managed, but yes there are cases (like using OLE Automation to control
omnipresent apps) that we may have to concede. But I personally would
not space for COM to breath.
Alas, you are in the group that may have invested so much on COM, or
depend on OLE Automation or Third-Party ActiveX Components so let's
see what I can help than further discuss the merit of the proposition.
> Component model specific code will not be part of the mono
> runtime, but part of an external library loaded at runtime (as
Very good decision. I just don't think Bonobo will fit in nicely as it
is very different from the other two, and from the COM-Interop
premises embedded in .NET.
> A few questions
> 1. Would the mono runtime be aware of common functionality that exists
> in all (currently proposed) component models; essentially the
> functionality of the Unknown interface (reference counting and interface
I fear you'll have to do that: Just to mimic correctly all the
COM-specific things that the Base Class Library has.
> 2. As MS has a base COM object wrapper (__ComObject), I was planning a
> similar one for mono. This wrapper would hold onto the unmanaged object
> pointer and provide additional functionality as required. Does this
> sound ok?
Yes, but you'll need a lot more baggage than this class. Issues with
threading-models and GC x ReferenceCounting clutter this space and are
mapped in this API surface.
> 3. I assume some sort of reference counting will take place. For
> simplicity, I was planning on AddRef'ing/Release'ing at every
> interaction. This is different that the MS implementation, I believe.
> For example, (again, I believe) MS keeps track of the IUnknown pointer
> and addref's only once upon entry into the managed runtime. Each
> unmanaged component then seems to be wrapped by only one managed
The problem is you can't Release freely as it may kill the object
prematurely. I'm not sure but I think the Disposable pattern is used
to control the lifetime of wrapped COM objects a bit better but some
exceptions to the rule may appear.
> 4. I assume each unmanaged interfaces will have a corresponding managed
> interface defined and tagged with appropriate attributes. The
> GuidAttribute would work for COM/XPCOM, but Bonobo takes a string for
> its QueryInterface.
Well that is what I said about Bonobo not fitting in. Let's look at
the problem from the developer that will be using it perspective.
Bonobo components are normally totally diverse from similar COM
components, it is hard to imagine having an interface-for-interface
match that would allow you to write a single hosting code to accept a
COM component and an equivalent Bonobo component. That's is easier
between COM /XPCOM as that was way XPCOM was written in the first
So If I want to write apps that use Bonobo components the most I would
expect is to be able to reuse "concepts", and similarly named classes,
but little mor than that.
So probably a BonoboObject (double-underscores aren't really needed in
this case) should be built as a counterpart to the __ComObject that
may be able to deal with COM and XPCOM.
> (Kornel mentioned having additional namespaces under
> System.Runtime.InteropServices, such as
No way. Adding subnamespaces in the ECMA/MS namespaces isn't allowed.
We can have a Mono.Runtime.InteropServices.Bonobo or a shorter and
appropriate Bonobo namespace.
Rafael "Monoman" Teixeira
I'm trying to become a "Rosh Gadol" before my own eyes.
See http://www.joelonsoftware.com/items/2004/12/06.html for enlightment.
More information about the Mono-devel-list