创建非托管 DLL 的 .NET 包装器有哪些优点和缺点？
是浪费时间还是有明显的&创建非托管 DLL 的 .NET 包装器有什么可衡量的好处？
更多信息：
- 我不控制 DLL，但我可以决定不将其替换为最新版本。
- DLL 有很多类。还有许多支持枚举。
- DLL 为项目提供了关键功能。
Is it a waste of time or there is an obvious & measurable benefit of creating a .NET wrapper of an unmanaged DLL?
More information:
- I don't control the DLL, however I can decide not to replace it with the newest version.
- The DLL has many classes. And many supporting enumerations.
- The DLL provides the project with critical features.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
这是一个奇怪的问题，但缺少重要的细节。如果您想从托管代码中使用这些类，那么您别无选择，只能为它们编写一个 C++/CLI 包装器。只有 C++ 编译器才能正确构造它们。 P/调用构造函数在技术上并非不可能，尽管找到其导出函数名称相当痛苦，但您无法猜测要为该对象分配多少内存。只有 C++ 编译器知道。
编写包装器并不是很困难，它很大程度上是机械的。您可以通过此答案中的链接找到更多详细信息。
This is a strange question but important details are missing. If you want to use these classes from managed code then you have no choice but to write a C++/CLI wrapper for them. Only the C++ compiler can properly construct them. P/Invoking the constructor isn't technically impossible, although it is quite painful to find its exported function name, you cannot guess how much memory to allocate for the object. Only the C++ compiler knows.
Writing wrappers isn't very difficult, it is largely mechanical. You'll find more details about it with links in this answer.
优点：
缺点：
如果您可以包装 DLL，然后还提供一个更简单、更小的接口来满足您的需要，那么它可能是值得的。
另外，我知道您说过您无法控制 DLL，但如果可以的话，.lib 的 C++/CLI 包装器是在 .NET 中使用非托管代码的更好方法（大多数情况下，这适用于其他人）请参阅此问题，或者您是否可以获得访问权限）。
Pros:
Cons:
If you can wrap the DLL and then also provide a simpler, smaller interface with just what you need, then it might be worth it.
Also, I know that you said that you can't control the DLL, but if you could, a C++/CLI wrapper of a .lib is a lot nicer way to use unmanaged code in .NET (mostly, this is for others that see this question, or if you can get access).
我知道的一些好处：
IntPtr，这对于经验不足的开发人员来说可能是麻烦和错误的根源。A few benefits that I know of:
IntPtrs, which can be a source of trouble and bugs for less experienced developers.您可以使用实现 IDisposable 的代码来包装对第 3 方代码使用的资源的管理，这将允许使用 .NET 垃圾收集来释放您不需要的资源（文件句柄等）。使用时间更长。
其他好处 - 几乎所有 3rd 方代码的标准包括：
您可以将大部分代码与 3rd 方 dll 将来可能发生的任何更改隔离开来。如果发生任何变化，您只需更改包装类中的实现即可。其余代码保持不变。
如果非托管代码中缺少其中任何一项，您还可以在包装类中构建缓存、验证和错误检查。
You can wrap the management of resources used by the 3rd party code with code that implements
IDisposablewhich will allow the .NET garbage collection to be used to free up resources (file handles etc.) that you are no longer using.Other benefits - standard for pretty much all 3rd party code include:
You are insulating most of your code from any changes that might occur in the 3rd party dll in the future. If anything changes you just have to change the implementation in your wrapper class. The rest of your code remains unchanged.
You could also build in caching, validation and error checking into the wrapper class if any of these were lacking in the unmanaged code.
优点：
1）如果算法位于非托管 dll 中，则算法具有某种安全性；
2）防止GC的瓶颈。完全控制内存；
缺点：
1) 如果您想使用 64 位 .Net 环境，则必须支持非托管 dll 的 32 位和 64 位版本；
2）必须在托管和非托管代码之间创建非常小的接口（桥），以防止速度下降。有时这是不可能的；
Pros:
1) Some sort of security of your algorithms if they are in unmanaged dll;
2) Prevent bottlenecks of GC. Full control of memory;
Cons:
1) You must support both of 32bit and 64bit builds of your unmanaged dll if you want to use 64bit .Net environment;
2) Must create very tiny interface (bridge) between managed and unmanaged code for prevent degradation of speed. Sometimes it is impossible;
如果您想在 C# 或 VB.NET 项目（或除 C++/CLI 之外的任何其他 .net 语言）中使用此 DLL，我看不到任何合理的替代方案（前提是您不打算从完全重新创建托管版本 DLL）划痕）。当然，您可以使用 COM 来代替，但在大多数情况下，从 .NET 客户端项目的角度来看，这会更困难、工作量更大，结果也更差。
编辑：好的，根据您的评论，DLL已经是一个 COM Dll。当然，那么您就不再需要 .NET 包装器了。我的回答是针对这样的情况：如果您有一个普通的旧本机 C++ DLL，其中使用 COM 意味着“向其添加 COM 包装器”。
If you want to use this DLL in a C# or VB.NET project (or any other .net language except C++/CLI), I don't see any reasonable alternative (provided you are not going to recreate a managed version DLL completely from scratch). Of course, you could use COM instead, but in most cases that be will be harder and much more work with a much worse result from the view of a .NET client project.
EDIT: ok, according to your comments the DLL is already a COM Dll. Then you don't need a .NET wrapper any more, of course. My answer was intended for the case were you have a plain-old-native C++ DLL, where using COM means "adding a COM wrapper" to it.