公开非托管 c++ 类库到c#
事实上，我有两个未镜像的 C++ 库，其中一个使用了另一个。 两者都很大，所以重写对我来说不是一个选择。
我读了一些关于创建托管 C++ 库的内容，该库包装了非托管代码。 但我真的不知道如何开始，以及如何将所有这些东西组合到一个项目中......
是否有任何分步指南或易于理解的示例来说明如何做到这一点？
TIA
i have in fact two unamaged c++ libraries, one of them makes use of the other. Both are pretty big, so rewriting is not an option for me.
I read some stuff about creating a managed c++ library which wraps arround the unmanaged code. But I don't realy get how to get started, and how to combine all this stuff in one Project...
are there any step by step guides or good easy to understand examples on how to do this?
TIA
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以考虑使用 ATL 为 C++ 代码编写 COM 包装器。 我在博客文章中展示了如何执行此操作。 这就是 Microsoft 公开他们用 C++ 编写的功能的方式（例如 Windows 7 库功能）。 COM 很容易被 .NET/C# 使用（请参阅 这篇文章）。 如果您选择这条路线，您可能会考虑 如果您不需要与其他人共享您的包装器，请免费注册 COM。
You might consider writing a COM wrapper for your C++ code using ATL. I show how to do this in a blog post. This is how Microsoft exposes functionality that they wrote in C++ (e.g. Windows 7 Libraries features). COM is easily consumed by .NET/C# (see this post). If you go this route, you might consider registration free COM if you don't need to share your wrapper with others.
您可以在同一个项目中编写托管和非托管 C++。 因此，您可以在托管 C++ 中编写一个包装器来调用本机 C++ 类等。然后在 C# 中，您的托管 C++ 类将像任何其他 .net 引用一样出现。 在这种情况下不需要使用 P/Invoke。
You can write managed and unmanaged C++ in the same project. So you can write a wrapper in Managed C++ that calls your native c++ classes etc. Then in C# your managed C++ classes will appear just like any other .net reference. No need to use P/Invoke in this case.
您有两种选择，一种称为 ijw“它只是有效”，您可以在其中编写托管 C++ 并调用非托管 C++。 另一个选项需要使用 pinvoke。
如果你使用 pinvoke，你会得到类似
C#
c++
的东西，如果你使用 SWIG，swig 会尝试自动生成上面的代码，但它是一个严厉的大师。
我曾经使用过托管c++，但我不太记得我对它的看法。
you have two options, one is called ijw "it just works" where you can write managed c++ and call unmanaged c++. The other option requires the use of pinvoke.
if you use pinvoke you'll have something like this
C#
c++
if you use SWIG, swig will try to autogenerate the above code, but it is a harsh master.
i used managed c++ once, but i don't remember quite what i thought of it.
我认为这取决于您实际需要公开多少库功能。
我不知道如何创建托管 C++ 包装器，但我个人使用了另外两种方法来解决此问题：
使用 SWIG 为您的 C++ 类自动生成 C# PInvoke 包装器。 这种方法可行，但只有在您需要公开大量类和成员时才真正值得。 根据我的经验，自动生成的代码仍然需要手动进行一些调整。
仅为您需要的功能编写非托管 C 包装器，从 DLL 导出它们，并手动编写需要导入到 C# 中的几个 PInvoke 包装器。 我发现这在某些情况下更合适，例如，有一个大型 C++ 类库可以执行不同类型的图像文件转换，但您真正想要公开的只是一个函数
DoTheConversion(LPWSTR inputFile)。 我的 C# 程序不需要了解底层类库的所有复杂性。I think it depends on how much of the library functionality you actually need to expose.
I don't know about creating a managed C++ wrapper, but I've personally used two other approaches to solving this problem:
Use SWIG to automatically generate C# PInvoke wrappers for your C++ classes. This sort of works but is really only worth it if you need to expose a lot of classes and members. In my experience, the auto-generated code still needed some tweaking by hand.
Write unmanaged C wrappers for just the functionality you need, export them from a DLL, and hand-code the few PInvoke wrappers you need to import into C#. I've found this is more appropriate in some cases, e.g. there's a large C++ class library that performs different types of image file conversions, but all you really want to expose is a single function
DoTheConversion(LPWSTR inputFile). My C# program didn't need to know all the intricacies of the underlying class library.阅读其中一些文章可能是一个开始 - 这是一个相当广泛的主题，并且没有“完美”的方法来做到这一点：
http://www.ondotnet.com/pub/a/dotnet/2004/03/29/mcpp_part3.html
http://www.codeguru.com/cpp/cpp/ cpp_management/interop/article.php/c6867
这些方法都没有使用 p/invoke，这是我们在我工作的项目中使用的方法，我们需要连接一个非常旧的 c++ 服务库。
Reading some of these articles might be a start - it's a rather broad subject, and there is no 'perfect' way to do it:
http://www.ondotnet.com/pub/a/dotnet/2004/03/29/mcpp_part3.html
http://www.codeguru.com/cpp/cpp/cpp_managed/interop/article.php/c6867
None of these approaches uses p/invoke, and it's an approach we use in the projects I work at where we need to interface an insanely old c++-service library.