[Mono-devel-list] COM Interop

[Andrew Weaver]

Jonathan,

We have a lot of legacy code packaged as COM objects that we're calling
using COM Interop from our C# .NET code on Windows.

To enable us to deploy our applications on Linux and Mac OS X using Mono we
think that SWIG (http://www.swig.org) shows some promise. Have you
considered it already? It may need a little more work to add some features
to the C# binding in order to fully support COM (as opposed to plain C++),
but that may be easier than, and preferable to modifying the Mono runtime.

The investigative work and preliminary tests were conducted by a colleague,
so I'm a bit vague on the details. But, if you're interested, then perhaps
we can help each other and the SWIG project for everyone's benefit.

--Andrew


On 25/7/05 11:57 am, "Jonathan S. Chambers" <Jonathan.Chambers at ansys.com>
wrote:

> Thanks for the response Rafael. I have a large amount of C++/COM
> code and migrating it all is not an option (due to shear size and
> performance reasons). I can port this code to *nix but have no way to
> call it.
> I have already discussed this with some members of the mailing
> list offline. Essentially, all I want to do is be able to call into a
> C++ vtable. All of my code is COM in origin; so all my calls are through
> interfaces (C++ abstract base classes), stdcall calling convention,
> HRESULT return value, etc. After some discussion, the idea of
> implementing COM Interop came up. But perhaps this is not the best
> solution. Perhaps I should just host the mono runtime and make any minor
> modifications I need to make. If there is not enough interest/benefit in
> COM Interop, then embedding mono to meet my needs might be the
> easiest/best solution.
> And just an FYI, I don't want all the COM/COM Interop
> functionality. I wanted the runtime to be able to call into the vtable I
> define through a corresponding managed interface, and the ability to
> handle casting by calling QI (if trying to cast an unmanaged component
> to a different interface, a cast can succeed if the QI succeeds even if
> the managed wrapper does not inherit from that interface). Any insight
> on this would be appreciated.
> 
> - Jonathan
> 
> -----Original Message-----
> From: Rafael Teixeira [mailto:monoman at gmail.com]
> Sent: Monday, July 25, 2005 1:30 PM
> To: Jonathan S. Chambers
> Cc: mono-devel
> 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,