关于是否使用原生 C++ 的建议DLL 与否：PINVOKE &编组？
最好的方法是什么......？
我有一些本机 C++ 代码，它使用大量 Win32 调用以及字节缓冲区（使用 HeapAlloc 分配）。我想扩展代码并制作一个 C# GUI...也许稍后使用基本的 Win32 GUI（用于没有 .Net 和有限的 MFC 支持的情况）。
(A) 我可以用 C# 重新编写代码并使用多个 PINVOKE...但即使将 PINVOKES 放在单独的类中，代码在所有封送处理中看起来还是很混乱。我还重写了很多代码。
(B) 我可以创建一个本机 C++ DLL 并使用 PINVOKE 来编组本机数据结构。我假设我可以在使用 C# 的项目中包含本机 C++ DLL/LIB？
(C) 创建混合模式 DLL（本机 C++ 类加托管引用类）。我假设这将使在 C# 中使用托管引用类变得更容易......但情况是这样吗？托管类会处理所有的编组吗？我可以在没有 .Net 的平台上使用此混合模式 DLL（即仍然访问本机 C++ 非托管组件），还是将自己限制在仅限 .Net 的平台上。
对于这些选项中的每一个，让我困扰的一件事是所有的编组。是创建托管数据结构（数组、字符串等）并将其传递给本机 C++ 类更好，还是反过来更好？
关于什么被认为是最佳实践的任何想法......？
更新： 我知道我可以从头开始重写本机 C++ 代码，但这意味着重复代码并阻止我轻松地在任何 Win32 应用程序中重复使用任何代码更新。我最关心的是在托管和非托管世界之间整理各种数据的最佳方式。对我来说，混合模式 DLL 看起来是最灵活的选择，但我想对潜在的陷阱有不同的看法。
What's the best way to do this....?
I have some Native C++ code that uses a lot of Win32 calls together with byte buffers (allocated using HeapAlloc). I'd like to extend the code and make a C# GUI...and maybe later use a basic Win32 GUI (for use where there is no .Net and limited MFC support).
(A) I could just re-write the code in C# and use multiple PINVOKEs....but even with the PINVOKES in a separate class, the code looks messy with all the marshaling. I'm also re-writing a lot of code.
(B) I could create a native C++ DLL and use PINVOKE to marshal in the native data structures. I'm assuming I can include the native C++ DLL/LIB in a project using C#?
(C) Create a mixed mode DLL (Native C++ class plus managed ref class). I'm assuming that this would make it easier to use the managed ref class in C#......but is this the case? Will the managed class handle all the marshaling? Can I use this mixed mode DLL on a platform with no .Net (i.e. still access the native C++ unmanaged component) or do I limit myself to .Net only platforms.
One thing that bothers me about each of these options is all the marshalling. Is it better to create a managed data structure (array, string etc.) and pass that to the native C++ class, or, the other way around?
Any ideas on what would be considered best practice...?
UPDATE:
I know I can re-write the native C++ code from scratch, but it means duplicating the code and prevents me from easily reusing any code updates with any Win32 application. What concerns me most is the best way to marshal the various data between the managed and unmanaged world. To me, a mixed mode DLL looks like the most flxible option, but I'd like to get a different perspective on the potential pitfalls.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么不直接使用.NET？在我看来，你的问题源于这样一个事实：你依赖于原始的本机库，但你没有提到它不能简单地在 .NET 中重新完成。
至于 .NET 原生互操作，PInvoke 很混乱，但它确实有效。如果你不能将原始 DLL 更改为 .NET，我会选择这样做。
Why not just use .NET directly? It seems to me like your problem arises from the fact that you are dependent on the original native library, but you don't mention that it can't simply be re-done in .NET.
As for .NET-native interop, PInvoke is messy, but it does work. I'd go with that if you can't change the original DLL into .NET.
如果编组对于框架来说是简单且容易处理的（所有内容都是 blittable 吗？），那么选项 C 将为您提供最少的工作。它还为您提供了一个挂钩自己的编组的地方。我很久以前写过一些关于日期类型之间的编组等的内容，但我想今天我会写一个 marshal_as<>托管类型和本机类型之间的过载。这将是最优雅的解决方案，也是最少的代码。
更新：找到我的旧文章 - 这是针对 PInvoke 的。 http://codeguru.earthweb.com/columns/kate/article.php /c4867/
Option C gives you the least work if the marshaling turns out to be simple and easy for the framework to handle (is everything blittable?). It also gives you a place to hook in your own marshaling. I wrote something about this ages ago marshaling between date types etc but I think today I would write a marshal_as<> overload between your managed and native types. It would be the most elegant solution and also the least code.
Update: found my old article - it was for PInvoke. http://codeguru.earthweb.com/columns/kate/article.php/c4867/