非托管和托管 C++ 之间的互操作性DLL
我目前有一个使用 MFC 的旧的非托管 C++ DLL。这个DLL有一堆多线程代码,是2003年使用VC6编写的。遗憾的是,这段代码不再起作用了。
我的任务是找到一种运行此多线程代码的替代方法,以便它能够按预期运行。在我之前有人已经用 C# 重写了它,我需要将该 C# 代码移植到 VC++。我做了一些研究,发现只需将 C# 代码移植到 VC++(使用 .NET 框架)就可以节省移植过程中的一些时间。但后来我意识到我的旧 MFC DLL 无法运行这个 .NET 代码。
我的想法是在 VC++ DLL 中编写这个多线程代码(使用 .NET 框架),并使用某种形式的互操作性,以便能够从旧 DLL 调用新 DLL 中的函数。
我研究了 COM 互操作性以及包装类。实现这一目标的最佳方法是什么?有任何教程可以帮助我完成这项任务吗? (我已经进行了一些广泛的搜索,并且有很多使用非托管 C++ DLL 到 C# DLL 的教程,但与我的情况相关的内容并不多)。
如您所知,我无法使用 /clr 编译旧的 DLL,因为该 DLL 也托管在旧的 Win32 应用程序中。使用 /clr 进行编译会导致应用程序崩溃,否则这已经完成了。
澄清一下:我很好奇为什么通过 COM 互操作从非托管 C++ DLL 调用驻留在 C# DLL 中的函数与使用托管 C++ DLL 执行完全相同的操作相比显得如此简单。我什至在 C# 和 C++ 之间进行了概念验证,但我一生都无法开始理解如何使用 C++ 执行完全相同的任务。是否恰好有一个简单的教程用于从非托管 C++ 到托管 C++ 调用一个简单(比方说“Add”)函数?
I currently have an old unmanaged C++ DLL using MFC. This DLL has a bunch of code which is multi-threaded and written back in 2003 using VC6. This code sadly doesn't work anymore.
I've been tasked with finding an alternative way of running this multi-threaded code so that it does function as intended. Someone before me had already rewritten it in C#, and I need to port that C# code over to VC++. I did some research and realized that I could save some time in the porting process by just porting the C# code to VC++ (using the .NET framework). But then I realized that my old MFC DLL cannot run this .NET code.
My idea is to write this multi-threaded code in a VC++ DLL (using the .NET framework) and using some form of interoperability to be able to call the functions from the old DLL to the new DLL.
I have looked into COM interoperability as well as wrapper classes. What is the best way of accomplishing this? Are there any tutorials that could help me with this task? (I've already done some extensive searching and there are a lot of tutorials using unmanaged C++ DLLs to C# DLLs, but not much that pertains to my situtation).
Just so you know, I cannot compile the old DLL with /clr as this DLL is hosted in an old Win32 application as well. Compiling with /clr causes the application to crash, or else this would have already been done.
TO CLARIFY: I'm curious as to why calling functions residing in a C# DLL from an unmanaged C++ DLL through a COM interop seems so simple compared to doing the exact same thing using a managed C++ DLL. I even have a proof-of-concept between C# and C++, but I can't for the life of me begin to understand performing the exact same task with C++. Does there happen to be just a simple tutorial for calling just one simple (let's say 'Add') function from unmanaged C++ to managed C++?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果您有一个(托管)DLL,无论它是用什么语言编写的,您都需要一个进程来运行它。如果您有一个本机进程(无论出于何种原因)不得使用 CLR,您不能直接从此进程中直接使用托管 DLL(任何依赖于进程内 CLR 的代码)。
您将需要第二个帮助程序进程来运行托管 DLL,例如,公开本机进程可以调用的 COM 接口。 (进程外 COM 服务器)
不确定包装类的含义,但托管 DLL 的进程外 COM 服务器可以解决这个问题。 (显然,对于管理帮助程序进程的正确注册和启动/关闭来说,这是相当过分的。)
稍微分解一下问题(据我所知):
如果这就是什么您正在寻找,那么这篇文章(只是 Google 的快速点击)可能会有所帮助:
http://www.codeproject.com/KB/COM/BuildCOMServersInDotNet.aspx
对于一般的 COM,我认为任何 COM 教程都应该涵盖您应该尝试做的事情。
If you have a (managed) DLL, regardless of the language(s) it is written in, you need a process to run it in. If you have a native process that -- for whatever reason -- must not use the CLR, that you cannot directly use a managed DLL (any code that depends on the CLR in-process) from this process directly.
You would need a second helper process that runs the managed DLL and, for example, exposes a COM interface that the native process could call. (out of process COM server)
Not sure what you mean with wrapper classes, but an out of process COM server for your managed DLL could do the trick. (Obviously, this is quite some overhand wrt. to managing the proper registration and startup/shutdown of the helper process.)
Breaking the problem up a bit (as far as I understand):
If this is what you are looking for, then this article (just a quick Google hit) may be helpful:
http://www.codeproject.com/KB/COM/BuildCOMServersInDotNet.aspx
For COM in general, I think any COM tutorial should cover what you are supposedly trying to do.