[Mono-devel-list] COM Interop

Mon Jul 25 14:05:30 EDT 2005

Sorry for the misquote.

-----Original Message-----
From: Kornél Pál [mailto:kornelpal at hotmail.com] 
Sent: Monday, July 25, 2005 2:00 PM
To: Rafael Teixeira; Jonathan S. Chambers
Cc: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-devel-list] COM Interop

Hi,

>> 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.

COM interop has to be implemented in the runtime because of AppDomain
independent CCWs and because a lot of wrapper code that has to be generated
by the runtime. Furthermore Import libraries generated by tlbimp.exe or
created by user code using the same techniques are empty methods that are
handled by the runtime.

>> 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
>> wrapper.
>
>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.

I don't see any problem around MS implementation regarding reference
counting so we should use the same rules.

Everytime you create a new RCW instance it will maintain its own reference
to the IUnknown (or derived) interface. It is not disposable and the
IUnknown interface will be released when it is collected by GC.
Marshal.ReleaseComObject was created to address this problem and this is the
recommended solution by Microsoft.

CCWs maintain a reference to the wrapped managed object. CCW will be
destroyed only when its IUnknown reference cound reaches zero. If the
managed object was destroyed because it's AppDomain was unloaded CCW still
will return MSEE_E_APPDOMAINUNLOADED (AppDomainUnloadedException) until it
is released.

>> 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.

I think COM interoc should be implemented using XPCOM because altough Bonobo
is for the same putpose as COM and XPCOM its characteristics are far away
from COM and thus existing COM interop infrastructure cannot cope with
Bonobo. (I mean the managed interfaces of COM interop: Marshal, Guid, ...)

>> (Kornel mentioned having additional namespaces under
>> System.Runtime.InteropServices, such as
>> System.Runtime.InteropServices.Bonobo).
>
>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.

It was actually "Mono.Runtime.InteropServices.Bonobo" that I mentioned for
the same reason as Rafael.

Kornél

----- Original Message -----
From: "Rafael Teixeira" <monoman at gmail.com>
To: "Jonathan S. Chambers" <Jonathan.Chambers at ansys.com>
Cc: "mono-devel" <Mono-devel-list at lists.ximian.com>
Sent: Monday, July 25, 2005 7:29 PM
Subject: Re: [Mono-devel-list] COM Interop

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
> requested).

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
> querying)?

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
> wrapper.

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
place.

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
> System.Runtime.InteropServices.Bonobo).

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.

> Thanks,
> Jonathan
>

Good luck,

--
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.
It hurts!