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?
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.
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.
I do not think this should be done using IPC. I think B should start A if user cancels download.
That is,
A dies as soon as B starts. B download and then applies the msiB starts A and exits. This happens irrespective of whether download completes or not
