-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cross-Platform COM Interop #10572
Comments
Have you looked at https://github.com/SharpGenTools/SharpGenTools ? We think independent tools like this is much better way to solve this. It has better performance and it is independent from the runtime so it is much easier to customize to your unique needs. |
@jkotas: Yes we looked at various tools, during the initial assessment when considering a Mono-based COM interop implementation, and later on when checking the NetCore migration scenarios. Though it looks much more promising to have these objects working first-class in the runtime, especially as the runtime has all of the required features on board but #ifdef'ed out for all the non-Windows platforms. It was astonishing to see COM interop running successfully on Mono (!) on Linux (!). After seeing that, running custom adapter generation tools feels like a major drawback. Especially on the runtime which has derived the original support for the feature in terms of internal structures and JIT features. |
Another point is that rather than customizing to our unique needs (which with open-source software often means fixing and patching) we'd rather have something which runs against the clear and well-defined COM interop rules, common for all. If the effort is roughly the same, we'd rather invest in making the standard interop work (for us and for everyone). It's hard to estimate how deep the rabbit hole is, actually. What pieces are missing on Linux? I wrote this issue to learn this in the first place. From reading the Mono code it seems that the big deal is to hack the type system and JIT and wherever you have to plug in CCW/RCW correctly, all of these mostly cross-platform — while the WinAPI-specific calls are not so mixed up with the logic. How true is this? |
@hypersw I think you are basically right in the sense that WinAPI use is orthogonal to CCW/RCW which is really nice from "Should be easy to port to non-Windows" perspective. What isn't obvious in the approach is the cost of maintaining this logic in the runtime. Your general suggestion of bringing out CCW/RCW support is and has been debated before. In the near future I am going to be starting that conversation in the open so more people can contribute. There is a strong opinion to have a pay-for-play mentality with cc: @jeffschwMSFT @luqunl |
We are interested in having first class support for running custom adapter generation tools in the build tooling so that it does not feel like a major drawback. The custom adapter generation tools were always part of the COM interop story actually: tlbexp, tlbimp, etc. Unfortunately, they were not designed to generate the actual code and there was still a lot of complex logic required in the runtime.
This architecture choice makes the COM and WinRT interop (the two are not cleanly segregated) very expensive to maintain. It is a lot of complex low-level code, our legacy baggage on Windows. We would like to avoid maintaining it on multiple platforms.
It is not required to hack the type system and JIT at all to plug in CCW/RCW correctly. The basic COM interop can be done just fine as SharpGen demonstrated. FWIW, Visual Studio parts that run on Unix have a pretty complete COM interop build on top of stock CoreCLR using the ICastable hook. The interop code is generated using MCG tool that is closed source equivalent of SharpGen - if we were doing it today, we would just use SharpGen instead. |
Hey! I'm the SharpGenTools maintainer. Just wanted to pop in to the conversation since I was tagged. As @jkotas mentioned, SharpGenTools enables COM interop relatively seamlessly. The 1.1 release (coming out after I get back from vacation) will make it even easier by adding support for auto-generating the C# stubs that enable passing .NET objects to native code. @hypersw: re customization: SharpGenTools supports an insane amount of customization. When SharpGenTools were just an internal tool for SharpDX, tons of customization features were added for obscure features or deficiencies in the mapping software at the time. Some examples are multiple methods of custom marshalling as well as runtime customizable vtable indices when needed.
I am very much looking forward to seeing low level runtime hooks like these exposed for interop libraries like SharpGenTools! I never realized there were hooks like ICastable in the runtime. |
(Addendum: Mono's COM support was never productized, it got a few contributions from the community, but the core team was never involved with it. I am sure that there are many things missing there. You really will be better off using something like SharpGenTools, even in Mono) |
I’ve just implemented something very similar: https://github.com/Const-me/ComLightInterop |
Now that the |
Goal: enable interop with native libraries with COM ABI and a reasonable subset of COM features on all supported platforms.
Related issue with generic discussion: https://github.com/dotnet/coreclr/issues/11279
This issue is to list specific work areas required to achieve the functionality:
RCW (Runtime Callable Wrappers).
CCW (COM Callable Wrappers).
Marshalling.
Supposedly, most of the implementation should already be available from the .NET Framework code. WinAPI implementations should be substituted with crude fallbacks for trivial cases (no activation scenarios, no cross-apartment call marshalling, no proxy/stubs).
Activation: manual from a DLL file, or possibly side-by-side scenarios. At first, activation is out of scope, suppose we create the first COM object with external means (e.g. Pinvoke + GetObjectForIUnknown).
Here are example scenarios for possible application of this functionality.
The text was updated successfully, but these errors were encountered: