HOWTO：在WindowsCE Compact Framework上从无人监管的C ++调用受管C＃接口 [英] HOWTO: Call Managed C# Interface From Unmanged C++ On WindowsCE Compact Framework
问题描述
我有大量的非托管Windows CE 5 C ++代码，它提供了一个UI，我想在一个新产品中使用它与大量的更新的业务和通信逻辑写在托管C＃在Windows CE 6和Compact Framework 。
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，以便我以后可以用托管版本或任何其他我选择作为一个前端。
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平台上的接口，这是我目前正在追求的策略：使用COM直接在非托管C ++库访问我托管库中的C＃接口，假设在WinCE中提供相同的工具。
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。它不能从我托管的C＃库，因为我以前使用它通过'#importSomeCPPLibrary.dll'语句。我相信它埋在.dll程序集中，以不同于过去的方式存储，因此，不能直接通过#import的库本身。我认为我可以#import一个typelib，但我找不到一种方法从我的托管的.dll中提取typelib，虽然我可以一起一个接口定义文件（.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.
-
我是吠叫错误的树？是否可以通过相应的COM接口在非托管C ++中使用托管C＃接口？
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文件使得通过COM在非托管世界中的所有接口通过AssemblyInfo.cs定义的GUID可用，或者我必须做更多的事吗？
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＃代码的基本问题？我刚刚在这里读到的是一个混合模式libarary与托管翻译层，以桥接非托管/管理差距。我不确定这是一个好的策略，因为呼叫响应速度是一个重要的因素，但从长远来看，它可能会更好，因为我打算重写UI到管理的C＃在某一点，因此把所有的努力，扔掉UI，而不是用更永久的业务/ comms逻辑？无论这个问题的答案，我仍然想解决使用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.
感谢您（集体）提供的任何洞察。
Thanks for any insight you (collectively) can provide.
james
推荐答案
您正在咆哮错误的树。为了使本地代码调用托管代码，本地代码必须启动CLR的执行引擎。这称为 CLR托管，并且不支持CF.这意味着你根本不能做到 - 即使是创意黑客（相信我，我已经在每一个胡同尝试）。
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).
这篇关于HOWTO：在WindowsCE Compact Framework上从无人监管的C ++调用受管C＃接口的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
