HOWTO: Call Managed C# Interface From Unmanged C++ On WindowsCE Compact Framework

Question

I have extensive unmanaged Windows CE 5 C++ code that provides a UI that I want to use in a new product by combining it with a large amount of newer business and communications logic written in managed C# on Windows CE 6 and the Compact Framework.

The UI may know about the business logic, but I want the business logic ignorant of the UI such that I can later replace it with a managed version, or any other UI that I choose as a front-end.

I found an article that describes how to use COM as the bridge in the Windows world, but I'm having difficulty applying it in the .NET CF under WinCE. In the past, I've imported type libraries and used COM calls (CoInitialize(), CoCreateInstance()) to obtain pointers to interfaces on other Windows platforms, and that's the strategy I'm pursuing at the moment: using COM directly in the unmanaged C++ library to access the C# interfaces in my managed library, assuming that the same facility is provided in WinCE.

Here's my problem: the typelib. It's not available from my managed C# library as I've used it in the past via a '#import "SomeCPPLibrary.dll"' statement. I believe it's buried in the .dll assembly, stored in a different manner than it has been in the past and hence, not directly available through a #import of the library itself. I think that I can #import a typelib, but I cannot find a way to extract the typelib from my managed .dll, and while I might be able to hack together an interface definition file (.idl) and use the platform's midl.exe to generate a .tlb from it, there's no guarantee that my .idl, and hence, resulting .tlb, would really match what is in my C# .dll. I don't even know if the platform midl.exe works in this manner but assume that it does.

1. Am I barking up the wrong tree? Is it possible to use a managed C# interface in unmanaged C++ through a corresponding COM interface?

2. Does setting the [assembly: ComVisible(true)] attribute in its AssemblyInfo.cs file make all interfaces in the managed assembly available through COM in the unmanaged world via the GUID the AssemblyInfo.cs defines, or do I have to do something more?

3. How do I get the typelib out of the managed .dll so that my unmanaged C++ library can #import it?

4. I tried adding my managed C# library project as a reference in the unmanaged C++ library project, but that didn't seem to help. Is such a reference relevant at all in this situation?

5. Is there a better approach to solving the basic problem of calling managed C# code from the unmanaged C++ world? Something I just read about here is a mixed mode libarary with a managed translation layer to bridge the unmanaged/managed gap. I'm not sure that is a good strategy as call response speed is an important factor, but might it be better in the long run as I plan to rewrite the UI to managed C# at some point, and thus puts all the effort on the throw-away UI rather than mucking with the more permanent business/comms logic? Regardless of the answer to this question, I'd still like to solve the problem of using COM, if for no other reason than curiosity.

Thanks for any insight you (collectively) can provide.

james

Answer 1

I have attempted to call C# from C++ in WinCE. I don't believe there is any COM support provided by the Compact Framework, so you can't use ComVisible(true).

I also couldn't find a way to host .NET in C++ because again the functionality wasn't exposed in the Compact Framework.

My solution was to create a stub C# application and communicate with the C++ host via Msg Queues. This also solves the data marshaling issue. Performance for my usage is fine. The biggest cost is the startup time of the stub which you'd have to pay anyway if you're complete app was C#.

Answer 2

You're barking up the wrong tree. In order for native code to call into managed code, the native code has to spin up the CLR's execution engine. This is known as CLR Hosting, and it isn't supported in the CF. This means that you simply can't do it - not even with creative hacking (trust me, I've been down every alley trying).