[Mono-dev] Com Interop Status
Jonathan S. Chambers
Jonathan.Chambers at ansys.com
Tue Jun 20 15:13:18 EDT 2006
I wanted to send an update on the Com Interop work I am doing. I wanted
to make sure that the path I'm taking looks ok. If the above patch looks
acceptable, I'll make some cleanups and would like to try and get some
changes committed. It's getting too big to keep track of.
A quick overview of what's in this patch:
1. All imported classes (marked with ComImportAttibute) actually derive
from __ComObject at runtime. I added code to set their parent correctly.
2. RCW (runtime callable wrappers) can be cast to interfaces which they
do not implement. To handle this functionality, I am reusing a lot of
the existing remoting infrastructure, especially using
IRemotingTypeInfo. This functionality is the majority of the patch. The
main difference is that I do not want to handle method calls via the
messaging mechanism, but rather by calling emitted wrapper methods.
3. Emitting of wrapper methods in C# using DynamicMethod. This is
handled in MSComInterop for MS Com Objects. It's very basic right now,
and needs some work. Basically, I need the functionality in the current
emit_marshal* methods in marshal.c to handle MarshalAs attributes, etc.
Does DynamicMethod sound like the right tool for the job here? That's
2.0 specific, so I guess Com Interop is a 2.0 specific feature unless
4. I want to be able to handle multiple component systems (COM and XPCOM
at least). This is accomplished via ComInteropSystemAttribute and
IComInteropSystem. Right now these are internal, but my goal is for
these to be external to some other assembly. If the
ComInteropSystemAttribute is not specified on an imported class, the
default component system is used (MS Com). However, the attribute can be
specified on imported classes to specify a different component system
(that must implement IComInteropSystem). For example, an XPCOM object
would be specified as follows:
public interface IFoo
void DoFoo( );
public class Foo : IFoo
void DoFoo( );
The XPComInterop type would be responsible for emitting the methods
(probably calling xptcall functions), and handling casting.
Any opinions are greatly appreciated.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 43244 bytes
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20060620/367e9658/attachment.obj
More information about the Mono-devel-list