What to do with interprocess communication between

Question

I need some help regarding interprocess communication.

I have an Application A and Application B. Application B purpose is to update Application A. As Application A can't update himself, there must be some dll's need to be updated that is why Applicaiton B is used. Appication A launches App B and App B closes App A and start updating A. The updater process is two step 1) Copies the msi bits 2) Install the bits

If the user cancels Application B in first step while App A is waiting, is there any way to signal Application A go to ahead launching Application A as updating is been cancelled.

What is the best way to achieve this and how? Is a Mutex the only solution?

Answer 1

I wouldn't use a Mutex for this. I'd use an EventWaitHandle. See Send message from one running console app to another for details.

Answer 2

Take a look at XDMessaging, which uses Windows Messaging or File IO for IPC. You can also use a global Mutex or Semaphore to achieve basic signalling.

Alternatively a basic approach (if this fits). The following starts Application B in a new process and blocks until it's exited. You can use exit codes to control behaviour.

Process appB = Process.Start("C:\\applicationb.exe");
appB.WaitForExit();
int exitCode = appB.ExitCode;

You could also create an update MSI that runs in parallel with some custom dialog, and use a custom action to close the other app before updating. There's a number of ways to achieve this, from killing the process to signalling via Windows Messaging.

Answer 3

I do not think this should be done using IPC. I think B should start A if user cancels download.

That is,

1. A dies as soon as B starts.
2. B download and then applies the msi
3. B starts A and exits. This happens irrespective of whether download completes or not