COM Interop Guidance

[wjk]

I am considering using CoreRT with my .NET Core compatible GUI framework. However, to fully implement the GUI feature support I require, I will need to do some COM interop. Having studied the CoreRT source code, I can tell that COM support is not currently implemented. To make this usable, here is what I would do:

1. Redirect creation of ComImportAttribute-decorated types to CoCreateInstance. Wrap the return value of that P/Invoke into something like this.
2. Redirect calls to methods of ComImportAttribute-decorated interfaces to code that takes the slot number of the method called, gets the corresponding vtable entry and performs a calli.

The problem is, though, this is not compatible in the slightest with the extensive but nonfunctional COM interop code already in the CoreRT repo. This COM interop code is only partially open-source (it references .NET Native functionality, as well as the MCG tool which is still proprietary), and is entirely WinRT-specific on top of that. Modifying the existing COM interop code to be compatible with desktop-style COM is currently far above my pay grade. Could anyone please give some pointers on how I or others might start working on implementing this? Thanks so much!

[jkotas]

cc @yizhang82 @tijoytom

[tijoytom-zz]

@wjk Thanks for your interest , as you mentioned most of the COM specific code in System.Private.Interop is tailored to work with the internal MCG tool. But the good new is that we are working on making the MCG tool public , we don't have any time lines yet. With MCG tooling you should be able to do Desktop style COM interop. I will keep you posted on the progress and once it's out in public you should be able to contribute.
@yizhang82

[wjk]

@tijoytom @jkotas I had a thought on how we might go about implementing CoreCLR-style COM interop on CoreRT. Rather than try to bring up the MCG-specific functionality in System.Private.Interop, I would instead use a subclass of CallInterceptor to redirect calls to a COM interface or class to CoreCLR, which would then do the COM interop as it always does. This is similar to what System.Private.Jit does, but for COM calls instead of ECMA-based reflection. Does this sound like a plausible approach?

[jkotas]

Does this sound like a plausible approach?

Hosting both CoreCLR and CoreRT in the same process sounds pretty non-trivial.

You may want to take a look at https://github.com/SharpGenTools/SharpGenTools . It is interop generator for COM that is very similar to MCG. I am not sure whether anybody tried it with CoreRT, but it should just work or it should be pretty easy to make it work. I believe that SharpGenTools are the easiest way to make COM work in CoreRT at this point.

[wjk]

SharpGenTools isn't an option for two reasons: One, I haven't found any good, real-world examples on how to marshal COM types using it. Two, Windows Forms/WPF don't use it, and I take dependencies on those in all my projects.

[jkotas]

Agree - making SharpGenTools work for Windows Forms/WPF would need some work. Still, I think it is easier to make SharpGenTools work than to make both CoreCLR and CoreRT run in the same process to reuse COM interop.

[jjxtra]

Unable to use corert until COM is built in, I manipulate Windows firewall and do not want to launch netsh process for each little rule change.