从非托管 C++ 调用托管代码 (c#) 的最佳方法
我们开发了由 C# 开发的对象集组成的 as/w 架构。它们广泛使用事件来通知客户端状态的变化等。
最初的目的是允许遗留代码通过 COM 互操作服务使用这些托管对象。这在设计规范中很容易编写，但我发现实际实现它会遇到更多问题。我已经搜索了很多小时，寻找使用此方法处理事件的良好示例。在我们沿着这条道路前进之前，我想确保 COM 互操作是允许旧代码调用新代码的最佳方式。
似乎有几个不同的选项：1) COM 互操作，2) 编写非托管包装类，3) 使用 /clr 编译器开关来启用托管对象的调用，4) 使用某种反向 pInvoke 调用。我还缺什么吗？
每个选项都有其优点和优点。缺点，我想知道最好的方法是什么。以下是针对每个
COM INTEROP 的具体问题/评论 - 看来事件处理是一个障碍。我们使用具有变量类型作为参数的事件。事件参数可以具有事件ID和对象。根据事件 ID，该对象将属于某种类型。这可以通过 COM 互操作来处理吗？许多暴露的对象都有属性。您无法在接口中声明属性，因此所有属性都需要相应的 get/set 方法。
编写非托管包装器 - 我认为这意味着使用 /clr 选项创建 DLL 以允许创建和调用托管对象并公开非托管对象。会对这些不受管理的客户端。我以前没有这样做过。这样做的好处/缺点是什么？
使用 /CLR 开关 - 我理解这意味着添加对托管对象的支持。这种方法有什么缺点？该选项是否支持上述事件？我们可以说，“这是托管库。将 /clr 编译器选项与您的遗留代码一起使用并使用它吗？”我不知道这会产生什么后果。有没有一个很好的例子来说明这是如何运作的？ （我确信有，我只是还没有找到它）
使用 REVERSE PINVOKE - 我不确定这到底是如何工作的，但是，从我所能找到的来看，这可能不是一个有效的解决方案。
那么，找到正确方向的决策树是什么样的呢？任何帮助表示赞赏。
- DP
We have developed a s/w architecture consisting of set of objects developed in C#. They make extensive use of events to notify the client of changes in status, etc.
The intention originally was to allow legacy code to use these managed objects through COM interop services. That was easy to write in the design specification but, I'm seeing that actually implementing it is more problematic. I've searched for many hours looking for a good sample of event handling using this method. Before we march down that path, I want to make sure that COM interop is the best way to allow legacy code to call our new code.
It appears there are several different options: 1) COM interop, 2) write unmanaged wrapper classes 3) use the /clr compiler switch to enable calling of managed objects, 4) use some sort of reverse pInvoke call. Am I missing any?
Each option will have its benefits & drawbacks and I'm wondering what the best way to go is. Here are specific questions/comments for each
COM INTEROP - It appears event handling is a hurdle. We use events that have variable types as parameters. An event parameter may have an event ID and an object. Based on the event ID, the object will be of a certain type. Can this be handled with COM interop? Many of the objects that are exposed have properties. You can't declare properties in an interface so all properties will need a corresponding get/set method.
WRITE UNMANAGED WRAPPER - I assume this means creating a DLL using the /clr option to allow creating and calling managed objects and exposing unmanaged objects. Would the client of these unmanaged. I haven't done this before. What are benefits/drawbacks of this?
USE THE /CLR SWITCH - I understand this means to add support for managed objects. What are the drawbacks of this approach? Does this option support events as described above? Can we say, "here's the managed library. Use the /clr compiler option with your legacy code and have at it?" I don't know the ramifications of this. Is there a good sample of how this works around? (I'm sure there is, I just haven't found it)
USE A REVERSE PINVOKE - I'm not sure exactly how this would work but, from what I've been able to find, this is not a likely valid solution.
So, what does the decision tree look like to find the correct direction? Any help is appreciated.
- DP
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为您最初的解决方案是最好的。 COM 互操作非常稳定并且有相当完善的文档记录。您需要做的就是确保可能从给定事件处理程序中弹出的所有不同事件对象实现相同的 COM 可见基本事件对象接口（具有事件类型 ID 等）。从那里，各个对象可以实现它们想要的任何其他接口，并且您的非托管代码可以根据您想要定义的任何标准来查找正确的“详细”接口。这真的没那么难。请查看 这篇 CodeProject 文章，了解端到端示例，其中包括非托管事件处理程序。
I think your initial solution is the best one. COM interop is stable and reasonably well documented. All you need to do is ensure that all the different event objects that might pop out of a given event handler implement the same COM-visible base event object interface (that has the event type id, etc). From there, individual objects can implement whatever other interfaces they want, and your unmanaged code can QI for the right "detail" interface based on whatever criteria you want to define. It's really not that hard. Have a look at this CodeProject article for an end-to-end sample including unmanaged event handlers.