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

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

 

[Pavel Minaev]

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?

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#.

 

[Nicholas Paldino [.NET/C# MVP]]

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#.

 

[Arne Vajhøj]

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?

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

Arne

 

[Arne Vajhøj]

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#.

Is named pipes faster than shared memory ?

Arne

 

[Arne Vajhøj]

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#.

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

 

[Jeroen Mostert]

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

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.

 

[Arne Vajhøj]

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.

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

Arne

 

[Bob]

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#.

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.

 

[Bob]

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

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.

 

[Bob]

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

Arne

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?

 

[Arne Vajhøj]

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?

Yes.

Arne

 

[Arne Vajhøj]

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.

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

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

Arne

 

[Bob]

Yes.

Arne

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?

 

[Arne Vajhøj]

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.

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").

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?

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

Arne

 

[Arne Vajhøj]

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?

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.

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

Arne