HOWTO：在WindowsCE Compact Framework上从非托管C ++调用托管C＃接口 [英] HOWTO: Call Managed C# Interface From Unmanaged C++ On WindowsCE Compact Framework

问题描述

我拥有大量的非托管Windows CE 5 C ++代码，通过将其与Windows CE 6和Compact Framework上以托管C＃编写的大量较新的业务和通信逻辑相结合，提供了我要在新产品中使用的UI

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.

UI可能知道业务逻辑，但是我希望业务逻辑不了解UI，以便以后可以用托管版本或任何其他版本替换它。我选择作为前端的UI。

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.

我找到了一篇文章，描述了如何使用COM作为Windows世界中的桥梁，但是我在应用时遇到了困难在WinCE下的.NET CF中。过去，我导入了类型库并使用COM调用（CoInitialize（），CoCreateInstance（））来获取指向其他Windows平台上的接口的指针，这就是我目前追求的策略：直接在假设WinCE中提供了相同的功能，则非托管C ++库可以访问托管库中的C＃接口。

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.

这是我的问题：typelib。我过去通过 #import SomeCPPLibrary.dll语句使用过托管C＃库中没有此功能。我相信它被埋在.dll程序集中，以与过去不同的方式存储，因此无法通过#import库本身直接使用。我认为我可以#import一个类型库，但是我找不到从托管的.dll中提取类型库的方法，尽管我可以将接口定义文件（.idl）一起使用并使用平台的midl.exe要从中生成.tlb文件，不能保证我的.idl以及因此得到的.tlb文件确实与我的C＃.dll文件中的内容匹配。我什至不知道平台midl.exe是否能以这种方式工作，但是假设它可以。

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. 我吠叫吗？上错了树？是否可以通过相应的COM接口在非托管C ++中使用托管C＃接口？

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?

是否在其控件中设置了[assembly：ComVisible（true）]属性AssemblyInfo.cs文件通过AssemblyInfo.cs定义的GUID在非托管世界中通过COM在托管程序集中提供所有接口，还是我需要做更多的事情？

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?

如何从托管的.dll中获取typelib，以便非托管的C ++库可以#import它？

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

我尝试添加托管的C＃库项目在非托管C ++库项目中作为参考，但这似乎无济于事。在这种情况下，这样的引用是否有意义？

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?

是否有更好的方法来解决从非托管C ++领域调用托管C＃代码的基本问题？我在这里刚刚读到的是带有托管翻译层的混合模式库，用于弥合非托管/托管差距。我不确定这是否是一个好的策略，因为呼叫响应速度是一个重要因素，但是从长远来看，可能会更好，因为我计划在某个时候将UI重写为托管C＃，从而将所有精力放在废弃的UI，而不是更持久的业务/通信逻辑？不管这个问题的答案是什么，我还是想解决使用COM的问题，只要出于好奇即可。

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.

推荐答案

我试图在WinCE中从C ++调用C＃。我不相信Compact Framework提供了任何COM支持，所以您不能使用ComVisible（true）。

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).

我也找不到方法可以在C ++中托管.NET，因为该功能并未在Compact Framework中公开。

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

我的解决方案是创建一个存根C＃应用程序并通过C ++主机与之通信消息队列。这也解决了数据编组问题。我使用的性能很好。最大的成本是存根的启动时间，如果您使用的是完整的应用程序，则无论如何都要支付存根的费用。

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#.

这篇关于HOWTO：在WindowsCE Compact Framework上从非托管C ++调用托管C＃接口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！