IPC between unmanaged and managed code

  • Thread starter Thread starter Alex Y Wang
  • Start date Start date
A

Alex Y Wang

Hi all, my current project is completely written in native C++, and
for some reason I need to write a standalone .Net program to do some
work for it. Therefore, I need to find an effective way of IPC between
my unmanaged code and managed code. What's most appropriate IPC
solution for this? Thanks in advance.

Alex Y Wang
 
I would agree, but one might want to think of hosting the components
that do the work in COM+ as well, which provide process isolation. One
wouldn't have to worry about creating the message pattern/protocol that is
needed when using a raw named pipe (unless of course, the operations are so
simple that the time needed to develop it is insignificant).
 
Hi all, my current project is completely written in native C++, and
for some reason I need to write a standalone .Net program to do some
work for it. Therefore, I need to find an effective way of IPC between
my unmanaged code and managed code. What's most appropriate IPC
solution for this? Thanks in advance.

Alex Y Wang

Hi Alex,
In addition to what Peter and Nicolas suggested, you could also use
Interop to take advantage of a .NET IPC, like remoting. In one of my
previous projects, I took this approach by implementing a remoting-
capable .NET class, and using it via Interop inside of a native C++
service, and it worked fine.

I think your choice of IPC really depends on what services you need
from the IPC, more than what language your two programs are written
in.

John
 
I would second (third?) what Peter and Nicholas have said - Pipes are the
easiest answer.

If you use .Net 3.5 (VS 2008) there is a complete set of classes for dealing
with Pipes in the .Net code. If you use an older verison (.Net 1.1 / .Net
2.0), you'll have to roll your own.

(Hrm. I'm not sure about .Net 3.0. I wonder if that has the Pipe classes?
They seem like something that would have been shipped as part of WCF, so I
would expect .Net 3.0 to have them...)

From what I remember, dealing with pipes from C++ / Win32 was pretty easy.
 
Chris,

Agreed with most you've said, except that pipes are part of 3.0 ; WCF's
"ipc" channel is not the same as a "named pipe", it's a channel that uses
Memory Mapped file(s) for IPC , named pipes are part of 3.5 (
System.IO.Pipes).

Willy.
 
Willy Denoyette said:
Chris,

Agreed with most you've said, except that pipes are part of 3.0 ; WCF's
"ipc" channel is not the same as a "named pipe", it's a channel that uses
Memory Mapped file(s) for IPC , named pipes are part of 3.5 (
System.IO.Pipes).

Willy.


Above is incorrect, System.Runtime.Remoting "Ipc" channel (V2.0) is mapped
over Shared Memory, while the WCF (V3.0) has a channel that uses "Named
Pipes", however, the pipe classes are private, so cannot be used from within
your code. Sorry for the confusion
 
Thanks a lot for the responses. I'll give named pipe a go then. All I
want to do is to have the .Net program to act as a temporary server.
It should send back responses as well as data to the native program
depending what requests it received from the native program.
 
Back
Top