Click here to Skip to main content
12,395,115 members (63,282 online)
Rate this:
Please Sign up or sign in to vote.
See more: C++/CLI C# .NET Interop Managed , +
I'm required to design the bidirectional distributed communication between legacy (MFC based VC++ application) and .NET GUI application (going to be built in C#). I have considered several approaches like Managed C++ (IJW), WCF (as a framework for communciations), Sockets, Named Pipes. Please suggest.
Posted 18-Oct-11 9:23am
SAKryukov 18-Oct-11 15:43pm
Same machine or network?
Rate this: bad
Please Sign up or sign in to vote.

Solution 1

First, "Managed C++" was superseded by C++/CLI which you tag, so this is hardly an option. Everything else really depends on details of your requirements and even of the level you are familiar with the technologies. In this case, it's not possible to justify any advice of the type "use just this, nothing else".

Unfortunately, WCF for unmanaged part (legacy MFC application) seems too much of a hassle to me, see[^].

Sockets or Named Pipes? Both seem reasonable. I think, with Sockets its somewhat easier to write more portable code.

Simon Bang Terkildsen 18-Oct-11 16:00pm
My 5. That's an interesting link, I thought of implementing WCF in C++ as a hassle, I might change my mind after reading it all.
SAKryukov 18-Oct-11 17:01pm
Thank you, Simon.
You probably mean native Win32 development.
Well, yes, even though I put this link to confirm my view at all this as a hassle, the advice in the article shows that this is not so much of a hassle as I would think before.
sundararaman 18-Oct-11 16:10pm
Thanks for your suggestions. I thought the same, but I'm thinking of a design solution that will provide you the following facilities.
1. Future is .NET. so Gradually my solution helps the legacy code to be converted into .NET.
2. if I have a WCF kind of communication framework, in future communication can be changed from one option to other like tcp to named pipes and so on.

SAKryukov 18-Oct-11 17:04pm
This is true. With WCF, you only change channels which are very independent from other aspects of communication. If this is an important priority for your project as well, it would be a huge plus in favor of WCF. And if you plan to get rid of native C++ part in future, this is an apparent benefit.
Espen Harlinn 18-Oct-11 19:20pm
SAKryukov 18-Oct-11 19:58pm
Thank you, Espen.
Rate this: bad
Please Sign up or sign in to vote.

Solution 2

Seems lake a hassle, to me, to write a host implementation of WCF in unmanaged C++.

This is an option, however I've never really used them so I don't know how feasible it is. That said if you need to communicate with something like Java where you can't use Named Pipes.

Named Pipes
I would go with this one, if you're using .NET 3.5 or above as Named pipes wasn't introduced before .NET 3.5 . Note if you intend on using Mono then I'm not sure if Mono even implements Named Pipes.

Is also an option, though I guess that it is not a good one in your case, without knowing exactly what you want to do.
Espen Harlinn 18-Oct-11 19:21pm
Simon Bang Terkildsen 19-Oct-11 11:23am
Thank you, Espen.
Rate this: bad
Please Sign up or sign in to vote.

Solution 3

If you want to get the job done in a hurry - use COM Interop[^]

.Net has great support for COM, and COM enabling an MFC app is usually a straight forward process.

Best regards
Espen Harlinn
sundararaman 19-Oct-11 9:13am
Thanks Espen. But I want to know how far COM interop can be used for distributed communication. I guess it will be very complex. My MFC application sits on one machine and my .NET GUI application sits on the other machine.
Espen Harlinn 19-Oct-11 14:01pm
That shouldn't be a problem ... DCOM (Distrbuted COM) is based on DCE RPC. You just have to make sure things don't get blocked by firewall, and that DCOM is configured correctly

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
Top Experts
Last 24hrsThis month

Advertise | Privacy | Mobile
Web01 | 2.8.160721.1 | Last Updated 18 Oct 2011
Copyright © CodeProject, 1999-2016
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100