3

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++?

Brutick
  • 83
  • 1
  • 9
  • *This code sadly doesn't work anymore.* -- In which context "doesn't it work" anymore? – Martin Ba Nov 21 '11 at 14:48
  • The code tends to crash the Win32 application. It also crashes inconsistently (i.e. never in the same method or the same cycle). Like I said, the code had be rewritten and redesigned in C#, but I need to port said code to VC++. – Brutick Nov 21 '11 at 14:52
  • If the code is there in C#, why do you want to port it? You can (I think, not too sure) expose a working COM interface from the C# code and call that COM natively from your native C++ app. You "just" need a separate process to host the managed code. – Martin Ba Nov 21 '11 at 14:57
  • I completely understand Martin, and trust me, I wish I could just use the C# code, but my boss is very stringent in terms of moving completely away from C#, as most people who are working here do not want to spend the time learning C# to support or add new functionality to the existing code. – Brutick Nov 21 '11 at 14:59
  • Do I understand this correctly, C# is *not OK* but using *managed C++/CLR* is OK? Talk about making sense :-D – Martin Ba Nov 21 '11 at 15:01
  • Yep, that's pretty much the situation, kind of odd, I know :P – Brutick Nov 21 '11 at 15:03

1 Answers1

0

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)

I have looked into COM interoperability as well as wrapper classes. What is the best way of accomplishing this?

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):

[oldish Win32 app (no! CLR)]
      <- normal DLL interface -> [native/MFC DLL (no! CLR)] 
                                                  <- via COM -> [stuff in a separate executable]

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.

Martin Ba
  • 37,187
  • 33
  • 183
  • 337
  • So you're saying I would have my unmanaged DLL start a new process running the COM server? – Brutick Nov 21 '11 at 15:01
  • Also does there happen to be a tutorial explaining how this works in more detail? I would like to try to just have a proof-of-concept version first showing that this is a possible solution, before implementing the 5000+ lines of code. I have never worked with COM interoperability before, but I did manage to get said interop working between an unmanaged C++ DLL and a C# DLL. – Brutick Nov 21 '11 at 15:06
  • 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++? – Brutick Nov 21 '11 at 17:01
  • Because Microsoft decided so. Really. MS "supports" Calling x -> COM, for any x ;-) && Calling managed.NET -> Native, via PInvoke. *But* there is no properly supported way to directly call .NET code from native/unmanaged code. (You should use a C++/CLR wrapper DLL, in which case the acces from native is splitted into native -> C++/native | C++/CLR -> managed.) – Martin Ba Nov 21 '11 at 18:31
  • Hmm, I see. Are there any tutorials you would recommend on accomplishing this functionality? Thanks for your answer :) – Brutick Nov 21 '11 at 19:47