Is anonymous pipes the right way to go here?

Question

I have an application that consists of two exe's. Let's call them MyApp.exe and MyAppStarter.exe. The reason I have MyAppStarter.exe is so that it can first check on the network if there is a new version of MyApp.exe available so that it can copy it before starting it - but that's somewhat beside the point now.

What I'd like to achieve is to be able to register a custom URL protocol handler for MyAppStarter.exe so that I can pass some kind of starting conditions to MyApp.exe. For example, if the user clicks on a link in an e-mail to myapp://userid=123, it should start the application and immediately view the user with userid 123. Or if the link is myapp://accid=456 it should immediately view the account with accid 456. This I know how to do, by registering the custom URL protocol handler for MyAppStarter.exe and then shell MyApp.exe with certain arguments. So far so good.

The problem now is that, should MyApp.exe already be running, I want MyAppStarter.exe to recognise that (this I can do) and give it focus (this I can also do) and instruct it to show the user or account or whatever with the specified id (this is where I'm stuck).

I've had a look at the MSDN documentation on How to Use Anonymous Pipes for Local Interprocess Communication. It seems straight forward enough but there are two things that I'm unclear about:

1. How do I communicate a Pipe Handle between the two so that a pipe can be established in the first place? Remember, MyApp.exe may already be running at the point where MyAppStarter.exe is executed.

2. In my scenario I'd imagine that MyAppStarter.exe will be the server while MyApp.exe will be the client. This means I'd have to set up a timer in MyApp.exe that checks the pipe every so often for an instruction from MyAppStarter.exe. I'm not mad about this idea. It's just that this requirement is a miniscule part of the operation of MyApp.exe so for it to fire a timer every second or however often just seems, shall I say, less than elegant. I would've liked it I could simply define a function in MayApp.exe, called void PerformInstruction(string instruction), which can be called from MyAppStarter.exe

Answer 1

When you use pipes/sockets you would have a thread running all the time to handle requests from MyStarterApp.exe. Your client will be waiting for ReadLine to finish and you will keep reading until you get some signal from the Server to FIN or the pipe is closed from the other side in which case you will the method would return NULL. Make sure to read up on behavior of StreamReader.

Within your MyApp.exe you would then require that thread to communicate with UI/consumer and select the appropriate user.

Answer 2

.NET Remoting makes this quite simple. This technology is considered outdated by many but it is still fully functional and ingrained in .NET. I doubt it will be gone any time soon. For local machine IPC or AppDomain "IPC" I consider Remoting to be quite a nice solution.

The IpcChannel class does just what you want. From the tutorial you can see how easy it is to get this going. Pipe handles do not need to be exchanged because endpoints are named.

Don't make the mistake to write your own binary protocol over named pipes. Feel free to choose something else than Remoting, though.

Make MyApp the server and MyAppStarter the client. If MyApp is not running the connection should fail immediately (no timeout required).