tags:

views:

486

answers:

2

I have one console app that is doing some lengthy syncing to an ftp server.
Another console app prepares a local filesystem with some needed updated files.
Then the second one will wait for the first one to finish before swapping a final directory name so it becomes visible on the web.

I searched for the best way to make the syncing app to communicate to the second app that it's finished it's job. It looks like Using Data Copy for IPC is the best suited solution for this.

Question is two fold:

  • Am I right? Is there a more straight forward way to get to the same result?
  • Is there a managed (.net) way to do this?
+3  A: 

Other popular options for IPC include:

  • Named Pipes
  • Remoting (.NET)
  • WCF

If you only need synchronization, you may consider a Semaphore, or Mutex object. There are classes which exist in the System.Threading namespace for .NET If you create named versions of these, then they apply to the whole machine.

Matt Brunell
I don't know half of the words you're saying, but will be doing some research :); 1UP for handing me the keywords :)
borisCallens
+2  A: 

If all you need is to notify one application that the other has completed its task, the easiest way would be to use a named EventWaitHandle. The object is created in its unsignaled state. The first app waits on the handle, and the second app signals the handle when it's finished doing its job. For example:

// First application
EventWaitHandle waitForSignal = new EventWaitHandle(false, EventResetMode.ManualReset, "MyWaitHandle");

// Here, the first application does whatever initialization it can.
// Then it waits for the handle to be signaled:
// The program will block until somebody signals the handle.
waitForSignal.WaitOne();

That sets up the first program to wait for synchronization. The second application is equally simple:

// Second app
EventWaitHandle doneWithInit = new EventWaitHandle(false, EventResetMode.ManualReset, "MyWaitHandle");

// Here, the second application initializes what it needs to.
// When it's done, it signals the wait handle:
doneWithInit.Set();

When the second application calls Set, it signals the event and the first application will continue.

Jim Mischel
This sounds mighty fine. Will test immediately and return here :)
borisCallens
Works like a charm :)
borisCallens