interprocess communication with and without .net

tags:

.net
ipc

views:

answers:

+1 Q:

interprocess communication with and without .net

I'm developing a .net WPF application, and I would like to put in a two way IPC mechanism. I realize named pipes and remoting are options, however I would like to make the mechanism not dependent on .NET for non-.NET applications to communicate with my application.

What does SO recommend as a solution to this? WM_COPYDATA?

Named pipes wouldn't be .NET specific. Neither would shared memory mapping or even TCP/IP. As for .NET remoting, I'd avoid it, even for cases where both sides are .NET.

Steven Sudit 2010-07-14 20:44:24

+1 A:

I would use named pipes, in this case.

Named pipes are fully supported in native code as well as .NET. They provide a very fast, efficient way of working, and are very easy to work with in .NET for your current development. This is a much better option (in just about every way, IMO) to WM_COPYDATA.

That being said, there are quite a few Interprocess Communication options. Many of these work both in .NET and native code, including:

Clipboard
COM
File Mapping
Pipes
Windows Sockets

Reed Copsey 2010-07-14 20:44:59

Agreed that they beat WM_COPYDATA. Not sure that they're as well-supported as TCP/IP solutions, though. (I'm including things like WCF here, not just plain HTTP.)

Steven Sudit 2010-07-14 22:09:19

@Steven: That's why I included Windows Sockets (last option), which includes TCP/IP (as well as UDP sockets).

Reed Copsey 2010-07-14 22:28:22

@Steven: Pipes are very well supported on Windows, though - so anywhere WM_COPYDATA would work, pipes should work.

Reed Copsey 2010-07-14 22:28:45

@Reed: While anything capable of SDK calls can do pipe I/O, .NET only got decent support in 3.5. Even then, it's just a thin wrapper over the OS and what it's wrapping isn't a whole lot of fun. I've used named pipes extensively for IPC and RPC, over the last 15 years, and I still don't like them. In the end, the IPC part is implemented over shared memory, just like TCP/IP to localhost, but you get all the complexity of Windows file security and lose access to SOAP, REST and all the rest. It's not a stupid choice by any means, but it wouldn't be where I turn to first. My $0.02.

Steven Sudit 2010-07-15 01:02:30

ansaurus

tags:

views:

answers:

interprocess communication with and without .net

related questions