Most robust way to implement single-instance Windows app?

  • Thread starter Thread starter Jen
  • Start date Start date
J

Jen

What is the most robust way to implement single-instancing for a Windows
app? I'm aware of the GetProcessByName method and the Mutex method. I've
GetProcessByName isn't very robust. What happens if the app crashes and
it's using the Mutex method? I don't want it to get in a situation where
the Mutex prevents the app. from starting when it really is ok to start. Is
the Mutex method the most robust? Any others?

Using .NET 2.0 and C#.
 
Jen,

If the app crashes, the Mutex should be disposed of, assuming that you
are using a using statement or a try/finally statement where you are calling
Dispose on the Mutex. Short of an error in the CLR, a regular exception in
this case will not cause the Mutex to hang around.

You might also want to check out this thread, which points to using the
WindowsApplicationBase class in the Microsoft.VisualBasic namespace which
handles exactly what you are looking for.

Hope this helps.
 
If the app crashes, the Mutex should be disposed of, assuming that
you are using a using statement or a try/finally statement where you are
calling Dispose on the Mutex. Short of an error in the CLR, a regular
exception in this case will not cause the Mutex to hang around.

It should be disposed of regardless, since even in native Win32, Windows
will dispose of the application's handle to the mutex when the application
terminates (normally or abnormally).

Pete
 
I'm trying the Mutex method. It seems to work on my development system but
on a test machine it doesn't prevent multiple instances. I'm doing
something like this:

bool firstInstance;
Mutex mutex = new Mutex(false, "klsjflksdjfklsdjflkd", out firstInstance);
if (!firstInstance)
return;
 
Jen said:
I'm trying the Mutex method. It seems to work on my development system but
on a test machine it doesn't prevent multiple instances. I'm doing
something like this:

bool firstInstance;
Mutex mutex = new Mutex(false, "klsjflksdjfklsdjflkd", out firstInstance);
if (!firstInstance)
return;

See http://pobox.com/~skeet/csharp/faq/#one.application.instance

(The paragraph starting with "One thing to beware of" describes your
situation.)
 
Jen said:
What is the most robust way to implement single-instancing for a Windows
app? I'm aware of the GetProcessByName method and the Mutex method. I've
GetProcessByName isn't very robust. What happens if the app crashes and
it's using the Mutex method? I don't want it to get in a situation where
the Mutex prevents the app. from starting when it really is ok to start. Is
the Mutex method the most robust? Any others?

Using .NET 2.0 and C#.


Do as Nicholas said and apply the using pattern on the Mutex...
...
bool firstInstance;
using (Mutex AppMutex = new Mutex(true, new
Guid("xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx").ToString(), out firstInstance))
{
if (firstInstance== true)
{
// run your program code from here
}
} // end using scope, mutex released here.
...

Willy.
 
What is the most robust way to implement single-instancing for a Windows
app? I'm aware of the GetProcessByName method and the Mutex method. I've
GetProcessByName isn't very robust. What happens if the app crashes and
it's using the Mutex method? I don't want it to get in a situation where
the Mutex prevents the app. from starting when it really is ok to start. Is
the Mutex method the most robust? Any others?

Using .NET 2.0 and C#.

A probable work around if you intend to avoid mutex, Give your main
form a unique name that has *good* chances of being unique and then
use the FindWindow API to retrieve its window handle.
You can check for the existence of the instance in the entry point of
your application and prevent from creating an instance if it is
already instantiated.

Raaj
 
A probable work around if you intend to avoid mutex, Give your main
form a unique name that has *good* chances of being unique and then
use the FindWindow API to retrieve its window handle.
You can check for the existence of the instance in the entry point of
your application and prevent from creating an instance if it is
already instantiated.

One problem with this method is that there is no way to guarantee one
instance of the application will have already created its window when the
next instance goes to check for it and vice a versa.

With the mutex, exactly one of the instances will actually create the
mutex, and the operating system guarantees exclusive access to the mutex.
There's no similar conflict resolution when checking for the application
window. The application can detect the case where the race condition
results in more than one instance running anyway, but then it still needs
to deal with deciding which instance "wins" and which instances have to
exit.

Basically, the mutex method is simple and provides guarantees that other
methods don't.

Pete
 
Mattias Sjögren said:
Willy,


Now there's an interesting way of generating a Guid string. :-)

Mattias,
LOL.
But seriously, at least it forces people to think about what it's meant for and what they
should do with it :-).

Willy.
 
Back
Top