By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
458,127 Members | 1,338 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 458,127 IT Pros & Developers. It's quick & easy.

how to check if app is already running?

P: n/a
Hi all

I'd like to avoid starting the same c# application twice on the same computer.
How do I check if it is already running?

Thank you
Sep 19 '06 #1
Share this Question
Share on Google+
14 Replies


P: n/a
private void Test_Launcb()

{
Process [] localByName = Process.GetProcessesByName("ProgramName"); //
Where ProgramName is the name of your Application

if (localByName.Length 1) // This copy makes 1

{

Application.Exit();

}

}


Hope this helps
Dan
"Alex K." <Al***@discussions.microsoft.comwrote in message
news:14**********************************@microsof t.com...
Hi all

I'd like to avoid starting the same c# application twice on the same
computer.
How do I check if it is already running?

Thank you

Sep 19 '06 #2

P: n/a
Alex,

Here is a response to a different post which answers your question:

http://groups.google.com/group/micro...128f9ddd957ada

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Alex K." <Al***@discussions.microsoft.comwrote in message
news:14**********************************@microsof t.com...
Hi all

I'd like to avoid starting the same c# application twice on the same
computer.
How do I check if it is already running?

Thank you

Sep 19 '06 #3

P: n/a
Hello Dan,

Take into account that this doesn't work in Terminal Services. In that case
u need to use Global Mutex

DTprivate void Test_Launcb()
DT>
DT{
DT>
DTProcess [] localByName = Process.GetProcessesByName("ProgramName");
DT// Where ProgramName is the name of your Application
DT>
DTif (localByName.Length 1) // This copy makes 1
DT>
DT{
DT>
DTApplication.Exit();
DT>
DT}
DT>
DT}
DT>
DTHope this helps
DTDan
DT"Alex K." <Al***@discussions.microsoft.comwrote in message
DTnews:14**********************************@micros oft.com...
DT>
>Hi all

I'd like to avoid starting the same c# application twice on the same
computer.
How do I check if it is already running?
Thank you
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche
Sep 19 '06 #4

P: n/a
It's also the worst way to do this. Scanning through the process list
is VERY costly.

It's easier to just set up a mutex that your app claims when your app
starts, and block out subsequent runs of it if you can't acquire the mutex.

See my other response for a more detailed way of doing this.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Michael Nemtsev" <ne*****@msn.comwrote in message
news:17***************************@msnews.microsof t.com...
Hello Dan,

Take into account that this doesn't work in Terminal Services. In that
case u need to use Global Mutex

DTprivate void Test_Launcb()
DTDT{
DTDTProcess [] localByName =
Process.GetProcessesByName("ProgramName");
DT// Where ProgramName is the name of your Application
DTDTif (localByName.Length 1) // This copy makes 1
DTDT{
DTDTApplication.Exit();
DTDT}
DTDT}
DTDTHope this helps
DTDan
DT"Alex K." <Al***@discussions.microsoft.comwrote in message
DTnews:14**********************************@micros oft.com...
DT>
>>Hi all

I'd like to avoid starting the same c# application twice on the same
computer.
How do I check if it is already running?
Thank you
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche


Sep 19 '06 #5

P: n/a
Thanks Dan, it works!

"Alex K." wrote:
Hi all

I'd like to avoid starting the same c# application twice on the same computer.
How do I check if it is already running?

Thank you
Sep 19 '06 #6

P: n/a

"Michael Nemtsev" <ne*****@msn.comwrote in message
news:17***************************@msnews.microsof t.com...
| Hello Dan,
|
| Take into account that this doesn't work in Terminal Services. In that
case
| u need to use Global Mutex
|
And TS means anything from XP and up.

Willy.


Sep 19 '06 #7

P: n/a
"Alex K." <Al***@discussions.microsoft.comwrote in message
news:FA**********************************@microsof t.com...
Thanks Dan, it works!
Don't do it - go with the mutex approach, which is much more efficient...
Sep 19 '06 #8

P: n/a
Can you supply the sample code for the mutex approach?

BTW, this method works fine for TS and XP. I have 15 machines in my
building alone as proof.

Dan


"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
"Alex K." <Al***@discussions.microsoft.comwrote in message
news:FA**********************************@microsof t.com...
>Thanks Dan, it works!

Don't do it - go with the mutex approach, which is much more efficient...

Sep 19 '06 #9

P: n/a
The number of machines running this isn't proof enough. If you have a
minimal number of processes on each machine, it doesn't matter how many
machines are running the app.

In the end, the process approach can take up to O(n) time, where n is
the number of processes on the machine. The mutex approach is always an
O(1) operation. Always guaranteed to be more efficient.

The Mutex approach is easy:

public static void Main()
{
// Created?
bool created = false;

// Create the mutex.
using (Mutex mutex = new Mutex(true, "MyMutex", out created))
{
// If this is not created, get out.
if (!created)
{
// Get out.
return;
}

// Run your app code here.
}
}

If you want your running app to handle command line parameters that are
passed to new instances that are run, then you should look at the
WindowsFormsApplicationBase class in the Microsoft.VisualBasic namespace, as
it handles this for you.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Dan Tallent" <sp**@microsoft.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
Can you supply the sample code for the mutex approach?

BTW, this method works fine for TS and XP. I have 15 machines in my
building alone as proof.

Dan


"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
>"Alex K." <Al***@discussions.microsoft.comwrote in message
news:FA**********************************@microso ft.com...
>>Thanks Dan, it works!

Don't do it - go with the mutex approach, which is much more efficient...


Sep 19 '06 #10

P: n/a
"Dan Tallent" <sp**@microsoft.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
Can you supply the sample code for the mutex approach?
1) Launch your Internet browser (IE, FireFox, Netscape, Opera Mozilla etc)

2) Navigate to http://www.google.com

3) Enter the text below in the box:

"C#" "global mutex" prevent twice

4) Hit the button
BTW, this method works fine for TS and XP. I have 15 machines in my
building alone as proof.
Of course it does - it's just not particularly efficient...
Sep 19 '06 #11

P: n/a
Thanks for the sample.

When I was referring to proof, I was talking about the program running on TS
or XP.
Someone on the thread said "Take into account that this doesn't work in
Terminal Services." This is not true.

I will most likely change my code to the Mutex method, but the other method
does work.
I agree the Mutex is more efficient, but if your talking about checking the
running processes,
ONLY when attempting to run the program, its unlikely this code will fire
very often. My example was when a different user
was logging into Windows. I wanted to suppress running the program again
if another user already started it. This was especially important on
a terminal services environment.

Thanks Again
Dan


"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.comwrote in
message news:%2****************@TK2MSFTNGP04.phx.gbl...
The number of machines running this isn't proof enough. If you have a
minimal number of processes on each machine, it doesn't matter how many
machines are running the app.

In the end, the process approach can take up to O(n) time, where n is
the number of processes on the machine. The mutex approach is always an
O(1) operation. Always guaranteed to be more efficient.

The Mutex approach is easy:

public static void Main()
{
// Created?
bool created = false;

// Create the mutex.
using (Mutex mutex = new Mutex(true, "MyMutex", out created))
{
// If this is not created, get out.
if (!created)
{
// Get out.
return;
}

// Run your app code here.
}
}

If you want your running app to handle command line parameters that are
passed to new instances that are run, then you should look at the
WindowsFormsApplicationBase class in the Microsoft.VisualBasic namespace,
as it handles this for you.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Dan Tallent" <sp**@microsoft.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
>Can you supply the sample code for the mutex approach?

BTW, this method works fine for TS and XP. I have 15 machines in my
building alone as proof.

Dan


"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
>>"Alex K." <Al***@discussions.microsoft.comwrote in message
news:FA**********************************@micros oft.com...

Thanks Dan, it works!

Don't do it - go with the mutex approach, which is much more
efficient...



Sep 20 '06 #12

P: n/a
Hi,

Windows XP Pro SP2, Workgroup

The mutex approach doesn't always work for me. It works in the following
scenarios:

1. User A attempts to launch a second instance of the process. User A
launched the first instance (ie same user, same workstation)

2. User A attempts to launch a second instance of the process. User B
launched the first instance. Both instances are running in the same
workstation (e.g. RunAs was used to change the owner of one of the processes).

It doesn't seem to work when user A attempts to launch a second instance of
the process where user B launched the first instance in a different
workstation (e.g. launch the process, switch to a different user (and
therefore a different workstation) and launch a second instance of the
process).

I always thought that named mutexes provided exclusivity over the entire
machine...
I've already tried using the Mutex constructor that takes a Security object,
granting full permission to everyone, but it made no difference. When I
examine the mutex names using SysInternals' Process Explorer, the name that I
gave the mutex is qualified and the qualifications are different on the two
processes.

Should a mutex work in this scenario?

Dave Razzetti
"Nicholas Paldino [.NET/C# MVP]" wrote:
The number of machines running this isn't proof enough. If you have a
minimal number of processes on each machine, it doesn't matter how many
machines are running the app.

In the end, the process approach can take up to O(n) time, where n is
the number of processes on the machine. The mutex approach is always an
O(1) operation. Always guaranteed to be more efficient.

The Mutex approach is easy:

public static void Main()
{
// Created?
bool created = false;

// Create the mutex.
using (Mutex mutex = new Mutex(true, "MyMutex", out created))
{
// If this is not created, get out.
if (!created)
{
// Get out.
return;
}

// Run your app code here.
}
}

If you want your running app to handle command line parameters that are
passed to new instances that are run, then you should look at the
WindowsFormsApplicationBase class in the Microsoft.VisualBasic namespace, as
it handles this for you.

--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Dan Tallent" <sp**@microsoft.comwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
Can you supply the sample code for the mutex approach?

BTW, this method works fine for TS and XP. I have 15 machines in my
building alone as proof.

Dan


"Mark Rae" <ma**@markNOSPAMrae.comwrote in message
news:%2****************@TK2MSFTNGP06.phx.gbl...
"Alex K." <Al***@discussions.microsoft.comwrote in message
news:FA**********************************@microsof t.com...

Thanks Dan, it works!

Don't do it - go with the mutex approach, which is much more efficient...


Dec 13 '07 #13

P: n/a
<A1******@community.nospamwrote in message
news:A8**********************************@microsof t.com...
Hi,

Windows XP Pro SP2, Workgroup

The mutex approach doesn't always work for me. It works in the following
scenarios:

1. User A attempts to launch a second instance of the process. User A
launched the first instance (ie same user, same workstation)

2. User A attempts to launch a second instance of the process. User B
launched the first instance. Both instances are running in the same
workstation (e.g. RunAs was used to change the owner of one of the
processes).

It doesn't seem to work when user A attempts to launch a second instance
of
the process where user B launched the first instance in a different
workstation (e.g. launch the process, switch to a different user (and
therefore a different workstation) and launch a second instance of the
process).

I always thought that named mutexes provided exclusivity over the entire
machine...
Only if the mutex is of a global type like....
"Global\MyMutex"

Willy.

Dec 13 '07 #14

P: n/a
Thanks Willy,

I'd just found an MSDN article that said exactly that!
Isn't it funny how a minute or two after you post a question on here, you
stumble across the solution somewhere else? Its happened a couple of times
now...

Dave Razzetti

"Willy Denoyette [MVP]" wrote:
<A1******@community.nospamwrote in message
news:A8**********************************@microsof t.com...
Hi,

Windows XP Pro SP2, Workgroup

The mutex approach doesn't always work for me. It works in the following
scenarios:

1. User A attempts to launch a second instance of the process. User A
launched the first instance (ie same user, same workstation)

2. User A attempts to launch a second instance of the process. User B
launched the first instance. Both instances are running in the same
workstation (e.g. RunAs was used to change the owner of one of the
processes).

It doesn't seem to work when user A attempts to launch a second instance
of
the process where user B launched the first instance in a different
workstation (e.g. launch the process, switch to a different user (and
therefore a different workstation) and launch a second instance of the
process).

I always thought that named mutexes provided exclusivity over the entire
machine...

Only if the mutex is of a global type like....
"Global\MyMutex"

Willy.

Dec 13 '07 #15

This discussion thread is closed

Replies have been disabled for this discussion.