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 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 2

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