What is the easiest way for two separate C# .Net apps to talk to each other on the same computer.

Question

I would like my two applications to be able to send strings to each other and depending on the string "do something".

This is for a pre-proof-of-concept-mockup type of thing so no security precautions needed and as inefficient as you want.

So how do I do this with a minimum of work on my part.

(You my dear fellow so user can work as hard as you please on the problem)

Answer 1

There are a lot of very easy ways for apps to communicate in very simplistic ways. I think some of the easiest would be the following

• Named Pipe
• Local Sockets
• Shared Memory

Answer 2

There are several mechanisms for this - probably the easiest to use is named pipes. I have not used it, but I understand the Windows Communication Foundation (WCF) is easy to use as well.

There are a bunch of articles on CodePoject about WCF :)

An advantage of using WCF is that it would let easily move your processes to different systems. (should that be practical for your scenario).

Answer 3

One way is to use .NET Remoting IpcChannel class to communicate across different processes on the same machine.

Answer 4

The easiest approach I can think of is creating a file that the other process checks for.

A more "advanced" and "sensible" way would be to use sockets and localhost.

And if I would want to actually implement it I would try and learn about proper IPC.

Answer 5

I'd go with sockets.

Answer 6

Message Queue

Answer 7

To what extent do they really, really need to be different applications?

Could you have two separate projects which you launch from a third project, on different threads?

static void Main()
{
    new Thread(Project1.Program.Main).Start();
    new Thread(Project2.Program.Main).Start();
}

At that point you could use static variables (in a fourth project, referenced by both of the first two projects) to set up a shared communication channel between the two of them. You could have two producer/consumer queues (look half way down the page), one for each direction, for example. (You'd want to make the queue just use strings, or make a generic one and then use ProducerConsumer<string> for example. If you can use the .NET 4.0 beta, you could use a BlockingCollection<string>.)

That would be extremely hacky - and without the isolation of even different AppDomains you could see some interesting effects in terms of static variables accessed from both "applications" but that's effectively what you're trying to achieve.

You should in no way take this implementation idea anywhere near production code - but for the situation you're describing, it sounds like "simple to implement" is the most important point.

Just in case the project hierarchy doesn't make sense, here's a graphical representation

        Launcher
       /        \
      /          \
   App 1       App 2
      \          /
       \        /
        \      /
      Shared stuff

(To make it even simpler you could actually just use one project, and make its main method launch two different threads using methods within the same project. The idea of it being two applications is all smoke and mirrors by this point anyway. On the other hand, it might make it easier to think about the different apps by separating the projects.)

Answer 8

WCF is a good way to good, even if once you start delving into it then it can become complicated.

You'd define a simple contract that accepts a string, then implement the contract in each application, doing whatever you want when the string arrives. Within an application you can self host the service, meaning the application itself hosts the service - so you don't need IIS. Host them on known ports, add a web service reference in each solution and away you go.