Best IPC mechanism between managed C# and unmanaged C++

  • Thread starter Thread starter Bob
  • Start date Start date
B

Bob

The question about IPC between managed vs unmanaged comes up once in a
while, and I generally see "Named Pipes" as the answer. But I was
wondering if there is anything new.

The app in this case will only be sharing short strings for the most
part, and the C++ part will eventually be rewritting in C#. So I'm
looking for anything that's fast and easy, but also not too ugly. Is
it still necessary to use named pipes?
 
The question about IPC between managed vs unmanaged comes up once in a
while, and I generally see "Named Pipes" as the answer. But I was
wondering if there is anything new.  

The app in this case will only be sharing short strings for the most
part, and the C++ part will eventually be rewritting in C#. So I'm
looking for anything that's fast and easy, but also not too ugly. Is
it still necessary to use named pipes?
Click to expand...

Do you actually need _inter-process_ communication? If so, named pipes
are still the fastest available communication mechanism for that, and
relatively easy to use as well, no matter whether you're using C++ or
C#.
 
Bob,

I would use some managed C++ in there and use WCF to communicate between
the two apps (whether or not you use named pipes as a channel becomes less
of an issue if you use WCF). This way, you don't have to worry about the
intra-process code when you move the C++ code to C#.
 
Bob said:
The question about IPC between managed vs unmanaged comes up once in a
while, and I generally see "Named Pipes" as the answer. But I was
wondering if there is anything new.

The app in this case will only be sharing short strings for the most
part, and the C++ part will eventually be rewritting in C#. So I'm
looking for anything that's fast and easy, but also not too ugly. Is
it still necessary to use named pipes?
Click to expand...

Regarding "anything new" and "still necessary", then named
pipes was first added to .NET in 3.5 !

Arne
 
Pavel said:
Do you actually need _inter-process_ communication? If so, named pipes
are still the fastest available communication mechanism for that, and
relatively easy to use as well, no matter whether you're using C++ or
C#.
Click to expand...

Is named pipes faster than shared memory ?

Arne
 
Nicholas said:
I would use some managed C++ in there and use WCF to communicate between
the two apps (whether or not you use named pipes as a channel becomes less
of an issue if you use WCF). This way, you don't have to worry about the
intra-process code when you move the C++ code to C#.
Click to expand...

WCF will have the nice property that the two apps are not
tied to the same box.

But even with the faster transports I would expect it to be
slower than the fastest available IPC mechanisms.

Arne
 
Arne said:
Regarding "anything new" and "still necessary", then named
pipes was first added to .NET in 3.5 !
Click to expand...
Well, they were first added to Windows in NT 3.1... It was nice of MS to
officially add them to the framework in 3.5, but code samples for P/Invoking
them are widely available.
 
Jeroen said:
Well, they were first added to Windows in NT 3.1... It was nice of MS to
officially add them to the framework in 3.5, but code samples for
P/Invoking them are widely available.
Click to expand...

It is still an indication that named pipes usage in .NET is
not yesterdays way of doing things.

Arne
 
Do you actually need _inter-process_ communication? If so, named pipes
are still the fastest available communication mechanism for that, and
relatively easy to use as well, no matter whether you're using C++ or
C#.
Click to expand...

By 'Interprocess', I am referring to two separate programs running on
the same machine. I'll check into named pipes then. Have not used that
in C# yet.
 
WCF will have the nice property that the two apps are not
tied to the same box.

But even with the faster transports I would expect it to be
slower than the fastest available IPC mechanisms.

Arne
Click to expand...

Thanks for your comments, Arne. The two apps will eventually be
integrated (the current hitch is that the older one was written with
unmanaged code, and it hooks into a complex unmanaged DLL. No fun in
C#).

So for now, the interest is in finding something that can be
implemented easily. Not sure if WCF would be the way to go, given the
limited support on the unmanaged side.
 
Regarding "anything new" and "still necessary", then named
pipes was first added to .NET in 3.5 !

Arne
Click to expand...

When I've looked into this in the past (pre .NET 3.5), I remember
seeing "Named Pipes" as the suggested approach. Would that have been
using PInvoke then?
 
Bob said:
When I've looked into this in the past (pre .NET 3.5), I remember
seeing "Named Pipes" as the suggested approach. Would that have been
using PInvoke then?
Click to expand...

Yes.

Arne
 
Bob said:
Thanks for your comments, Arne. The two apps will eventually be
integrated (the current hitch is that the older one was written with
unmanaged code, and it hooks into a complex unmanaged DLL. No fun in
C#).

So for now, the interest is in finding something that can be
implemented easily. Not sure if WCF would be the way to go, given the
limited support on the unmanaged side.
Click to expand...

You can find a SOAP toolkit for unmanaged C++.

But I don't think it is the way to go.

Arne
 
Yes.

Arne
Click to expand...

I'm surprised that IPC between managed/unmanaged code hasn't been
addressed more thoroughly prior to .NET 3.5. You'd think that those
functions would have been key to getting managed code adopted.

I did check on the new .NET 3.5 Named Pipes calls. Turned up a couple
MSDN pages. Very few Google hits, and very little sample code. Nothing
on CodeProject either. I had expected to find threaded classes and
frameworks that take advantage of the new classes. (Unless someone
knows where samples for this would be located, I suppose it's "roll
your own").

Does this all indicate that few people are doing extensive IPC between
managed and unmanaged code?
 
Bob said:
I'm surprised that IPC between managed/unmanaged code hasn't been
addressed more thoroughly prior to .NET 3.5. You'd think that those
functions would have been key to getting managed code adopted.
Click to expand...

The Win32 API is huge.

They needed to prioritize.

And they did.
I did check on the new .NET 3.5 Named Pipes calls. Turned up a couple
MSDN pages. Very few Google hits, and very little sample code. Nothing
on CodeProject either. I had expected to find threaded classes and
frameworks that take advantage of the new classes. (Unless someone
knows where samples for this would be located, I suppose it's "roll
your own").
Click to expand...

It is rather straight forward to use. No need to write much about it.
Does this all indicate that few people are doing extensive IPC between
managed and unmanaged code?
Click to expand...

I don't think that indicates so, but I do believe that IPC between
managed and unmanaged code is a relative rare thing.

Arne
 
Bob said:
A couple followup questions, since you seem familiar with the new
Named Pipes classes:

Is there an easy way to run asynchronously... to block the thread
until data is received?
Click to expand...

I have only used them sync.

But the classes have the usual .NET IO way of doing async.
Also, is there a convention for which program is the 'server' and
which is the 'client'? The limited sample code that I've seen set up
the transmitting program as the client, but I'm not sure what
difference that makes.
Click to expand...

There is a server class and a client class. Both are
bidirectional.

Arne
 
Back
Top