Click here to Skip to main content
15,914,221 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi, I'm looking for a way to create and distinguish multiple instances of my program.
What I first thought was to define a description for my assembly so I could modify it when the exe was called and identify the instance of my app but after some searching I'm starting to realize this might not be possible.

What are my choices here? how can we identify the processes in the task manager if possible??

Thanks a lot!
Posted

I don't think it can help you to tell the difference between those instances. Even if you could change the assembly description, before doing that you would need to know is this a first instance of not, so you would need to communication to other instance(s) anyway.

First, understand this: the instances of the same application are completely different processes, isolated from each other exactly as well as any other different processes. Also, understand that an assembly is not a process. An assembly consists of executable modules (VS can create only one), and a process can be started from the name of a main executable module of any assembly. So, the conclusion is: what you need is communication between different processes, and this is called IPC.

There are a number of different methods using to tell the different processes of the same application apart. One simple method is using System.Diagnostics.Process.GetProcesses, see http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx[^].

A process can look at the already running processes and see if one or more instances of the same application is already running. You need to be careful: a completely different application can have the same name, a title of the main window, etc. You can compare them by the name of main executable module. In this case you won't be able to identify the "same" application which was copies (as a set of executable files) to other directory. This problem really does not have a solution, simply because the definition of "same application" does not even exist. I would consider the application to be the "same" if it was started from the same main executable module (found for a currently running code as System.Reflection.Assembly.GetEntryAssembly().Location).

If you simply need to develop a single-instance policy, one of the very best .NET methods is using classic remoting. An application should act as a service part. Before doing that, and application should try to connect to an existing server. It it is successful, the application runs in a second instance and should be terminated pretty soon. An exception in connection means that there is no a service part, so the currently running application is the first instance and it should act as a server. As (or if) all instances run on the same machine, you need to use IPC channel (the one based on named pipes). For the name of the channel, you can use the same thing: a name of the main executable module; which is guaranteed to be unique in the local system.

You can use the same kind of IPC in more general cases. Another means of IPC include shared memory block, self-hosted WCF, named Mutex, etc.

—SA
 
Share this answer
 
Comments
mario_silent 3-Oct-11 14:44pm    
Great explanation, very informative SAKryukov! actually I have kind of a messy workflow with the application, I have a Windows-hosted WCF service that launches 3 different apps in a server, a wcf client that opens a channel to the remote server and specifies the exe to launch on the server. The problem is that they reported 1 of those exes is getting stuck executing some queries on the server so they have to terminate the process through the task manager buuut the exe can be executed by many clients so it can have multiple instances. The problem is finding out which client launched the exe so they can terminate the aprropriate one. What do you think is the best way around it?? I don't think the System.Diagnostics.Process class can give me a way to discover the appropriate process...

Thanks a lot for the quick reply
Sergey Alexandrovich Kryukov 3-Oct-11 18:10pm    
Ideal solution would be: think about re-using WCF functionality the way similar to the one I describe with the use of classical remoting. Just one mechanism might be better than two ones, unless you have to do something overly tricky. The rest of it really depends on your detail. I still don't clearly see if you need to keep just one instance of there is a situation when you need or allow more. One usually required piece of functionality is to activate the UI of the first instance of the application; sometimes, passing command line parameters from one instance to another is required. Both WCF and classic remoting can be re-used to do this additional chores. Just something for you to think about.
--SA
Espen Harlinn 3-Oct-11 14:59pm    
Excellent reply, Sergey!
Sergey Alexandrovich Kryukov 3-Oct-11 16:44pm    
Thank you, Espen.
--SA
The Process class can, as SAKryukov mentioned, be used to solve your problem. The Process.Id[^] is the system-generated unique identifier of the process that is referenced by the Process instance.

Best regards
Espen Harlinn
 
Share this answer
 
Comments
mario_silent 3-Oct-11 15:10pm    
Yeah I think that'll help, I'll figure out a way with the Id.
Thanks a lot to everyone who replied

Best regards
Espen Harlinn 3-Oct-11 18:47pm    
That's good ...
Sergey Alexandrovich Kryukov 3-Oct-11 16:45pm    
Good point, my 5.
--SA
Espen Harlinn 3-Oct-11 18:47pm    
Thanks Sergey :)
You can use the Hashcode to distinguish multiple instances - see here[^].
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900