Multiple app instances, and passing parameters

[Peter Reinhold]

Hi All,

I am developing a small utility, and have run into a small challenge.

The util is used for performing operations on a bunch of files, and it
can be triggered from the right-click menu when you click on a file.

My problem now is, if the util is already running, I want to stop a
new instance from spawning, and, at the same time, pass the parameters
from the soon-to-be-despawned instance, to the main instance.

My solution at this moment is to open a socket on LocalHost when the
first instance starts, and then on the following, check if something
is bound in the specific port, and then pass the parameters via TCP.

But, can this be done more elegantly?

The reason i'm asking is that this approach seems very "hacky" to me,
but, on the other hand, it works, and I haven't been able to make it
loose parameters or misbehave in other ways.
/Peter

[Arnshea]

On Sep 26, 4:02 pm, Peter Reinhold <[e-mail]:

Hi All,

I am developing a small utility, and have run into a small challenge.

The util is used for performing operations on a bunch of files, and it
can be triggered from the right-click menu when you click on a file.

My problem now is, if the util is already running, I want to stop a
new instance from spawning, and, at the same time, pass the parameters
from the soon-to-be-despawned instance, to the main instance.

My solution at this moment is to open a socket on LocalHost when the
first instance starts, and then on the following, check if something
is bound in the specific port, and then pass the parameters via TCP.

But, can this be done more elegantly?

The reason i'm asking is that this approach seems very "hacky" to me,
but, on the other hand, it works, and I haven't been able to make it
loose parameters or misbehave in other ways.

/Peter

If you've got an overactive QA person, one who likes to double click
on things as fast as they can to see if anything breaks, you might
want to use a mutex (use an app-specific, unique name). The first
instance would hold the mutex until it exits; anything else would
queue up the request via TCP.

Remoting is another way to handle the interprocess communication but
if the parameters are relatively simple it might be overkill...

[Peter Reinhold]

want to use a mutex (use an app-specific, unique name). The first

instance would hold the mutex until it exits; anything else would
queue up the request via TCP.

It might be a good idea to implement a combination of a mutex and then
if that is set, deliver parameters via TCP

Remoting is another way to handle the interprocess communication but
if the parameters are relatively simple it might be overkill...

I actually checked out remoting during my first analysis, and I deemed
it to be overkill for passing a filename between two applications.
/Peter

[Peter Reinhold]

On Sep 26, 10:15 pm, "Nicholas Paldino [.NET/C# MVP]"
<[e-mail]:

The general concept is actually very sound, IMO, as this is exactly what
the WindowsFormsApplicationBase class in the Microsoft.VisualBasic namespace
does.

Ok, thats nice to hear :)

Thanks for the links Nicholas, i'll check them out at once.
/Peter

[Peter Duniho]

Peter Reinhold wrote:

>want to use a mutex (use an app-specific, unique name). The first
instance would hold the mutex until it exits; anything else would
queue up the request via TCP.

It might be a good idea to implement a combination of a mutex and then
if that is set, deliver parameters via TCP

I agree. I think that's what Arnshea was suggesting.

>Remoting is another way to handle the interprocess communication but
if the parameters are relatively simple it might be overkill...

I actually checked out remoting during my first analysis, and I deemed
it to be overkill for passing a filename between two applications.

One advantage remoting might have is to avoid the issue of what to do if
the port you've selected for your socket is already in use by something
else. I haven't used it myself, but I assume it uses a communication
mechanism that ensures a connection between the two endpoints can always
be created.

If you already have some mechanism for having the port auto-selected,
but still discoverable by subsequent instances of the application, then
I'd agree remoting is probably overkill. Otherwise, you might consider
it still. :)

Pete