Click here to Skip to main content
15,885,216 members
Please Sign up or sign in to vote.
4.00/5 (1 vote)
See more:
In my C# application I'm going to check if another C# application is running, and if so, I'd like to call into it and open a window in that app.

Anyone know if this is possible and if so, how?

Thanks
Posted
Comments
Sergey Alexandrovich Kryukov 5-Oct-11 16:40pm    
Do you have source code of this another application?
--SA
Kevin Marois 5-Oct-11 16:44pm    
Yes

A call? Of course no. The whole notion of a call is only applicable to a method. Well, to a property, too, if a property is considered as its getter or setter.

However, the functionality you want is quite possible.

First, you should seriously think if you really want to communicate with a separate process. This approach has a lot of problems. As another application is in C#, think about using is as a class library instead and run the methods of this library in the host process. If you need working of this method in parallel you can run some library code in a different thread, but still in the same process. This is million times better. Separate processes are well isolated, they are not primarily designed to be integrated together. So running the code in a single process is absolutely the best you can do.

No assume that you cannot do it. Maybe you don't have the source code of this application, and available code is not suitable to serve as a library (yes, you can use any assembly compiled as .EXE application as a library in .NET). Taking into account that the different processes are well isolated, but you still need communication between them, you need what? Right, only one thing: IPC (Inter-Process Communication).

There are different ways to do IPC. Probably your best bet is using WCF, self-hosted by the "another application", classical remoting can also do the job. In this case, from the standpoint of your host process the communication may look exactly like a method call, but in fact it will be a call to a method of WCF or remoting object proxy. If your processes are on the same machine, the transport channel can be based on named pipes, and such channel is also called IPC. Other suitable methods include TCP sockets (better using TcpListener/TcpClient), named pipes used directly, and more. I still think WCF is better.

Start from here:
http://msdn.microsoft.com/en-us/library/ms731758.aspx[^],
http://msdn.microsoft.com/en-us/library/bb332338.aspx#msdnwcfhc_topic3[^],
http://www.youtube.com/watch?v=FPrQPA9QmUw[^];

on CodeProject:
WCF Comparison with Web Services and .NET Remoting[^],
A Quick and Dirty WCF Service and Client (Using WCF and Winforms)[^],
Writing your first WCF Service[^],
WCF (Windows Communication Foundation) Introduction and Implementation[^].

[EDIT]

To see the status of a process, use the class System.Diagnostics.Process, http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx[^].

—SA
 
Share this answer
 
v2
Comments
Espen Harlinn 5-Oct-11 17:10pm    
5'ed - even if I would go for COM interop as long as everything is running on the same computer. I thuoght you would kind of like the AppInit_DLLs solution, as it has many other uses too.
Sergey Alexandrovich Kryukov 5-Oct-11 17:18pm    
Thank you, Espen.
I would refrain from using obsolete COM in .NET unless some solution is already using it.
--SA
Espen Harlinn 5-Oct-11 18:06pm    
With windows 8, COM is about to become fashionable again as the C++ projection relies on an enhanced version of COM - it's also pretty easy to implement and deploy COM a based solution for this kind of problem :)
Sergey Alexandrovich Kryukov 5-Oct-11 18:22pm    
What the news! I never thought it could happen. What are they thinking, I wonder?
I remember, someone explained the problems of Microsoft by the fact that "Bill Gates has no vision". But compared to what it is now...

Well, I still think for simple task like this one there is nothing more smooth then using self-hosted WCF. It really looks like a call, and the activation is easier than in classic remoting...
--SA
To load a .dll in every process, add its name to the AppInit_DLLs value in following registry key:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Windows

Whenever a process starts, the system loads the specified .dll in the context of the newly started process before calling its entry-point function.

This allows you to create code that can be "attached" to existing programs.

This can be used or misused, and the dll has to be native.

If you have the source code for the other application, expose functionality using COM interop, remoting, WCF, or any other interprocess communication technology you might fin appropriate.

Best regards
Espen Harlinn
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 5-Oct-11 17:21pm    
Espen, it is not native. Both applications are in C#, look at the question.
Also -- System.Diagnostics.Process; I updated my solution.
--SA
Espen Harlinn 5-Oct-11 18:07pm    
I know, but you can always invoke the .Net runtime from native code.
Hi,
Yes you can what u need to do is u must use named pipes to acheive this.
u have to write in both the application and by using the name of the pipe in another c# application u can do this.
i am just suggesting the approach...i did the same before in one application..
All the best
 
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