1

I need help in determining if this is even possible. I have to applications; app1 and app2. app1 is the main app and app2 is a helper app (startup service that launches app1 when the machine starts and ensures app1 is always running).

Is there a way for me to write these two apps to where, if an event is detected by app2, it can connect to the currently running app1 and fire off one of its methods? Can I access / modify any of app1's variables from app2?

I have looked quite extensively, but the closest I get to my answer is the Win32 / API FindWindow option to press buttons or change text. I do not think this is what I am looking for.

Is what I want possible?

Any help is appreciated, thanks!

MattCash
  • 81
  • 2
  • 9

1 Answers1

1

There are many ways to communicate between applications each with different tradeoffs.

Probably the most common and preferred method for two applications to communicate with each other in the Windows OS is Interprocess Communications (IPC) as discussed in another thread here. This alone gives you several different options among them being RPC, Pipes, Winsock and I'll lump WCF in here as well.

You could also resort to manipulating files and utilizing a FileSystemWatcher or create a similar solution for Registry watching.

None of these solutions, however, allow you to mutate an applications data or directly invoke methods. Chances are you really don't require this as any communication mechanism allows you to alter a programs state indirectly through a more well defined API. This is the basic idea of abstraction.

You could technically utilize the Process class or possibly an AppDomain and come up with a workaround via Reflection. This isn't exactly what you are looking for either and maintenance can be troublesome. It is good to know about these technologies for other purposes though. Here are a few interesting posts on the subject: Cross AppDomain Call, Example use of AppDomain, Example use of Process, another handy type to look at.

There is yet another way, albeit a bit overboard for your situation, for completeness I will mention it anyways. You could write a Kernel Mode application. This is mostly if you want to interface with new hardware and even in that case some drivers can still be written in user mode. If you are to dive into kernel mode application development you are no longer living in the safety zone of virtual address spaces, if you make a mistake you no longer crash your program, you blue screen the OS. During development it would be wise to use a hard disk cloning utility such as Clonezilla to start from a clean slate if you do hose the OS. You would also need to familiarize yourself with other kernel mode debugging tools again this is a fair bit out of scope.

Summary

I realize none of these methods will technically give you the exact behavior you mention in the question, but I would say the IPC approach is your best bet for handling a pattern where you are creating a Service/Stand alone Application pair.

Community
  • 1
  • 1
Matthew Sanders
  • 4,875
  • 26
  • 45
  • Thank you so much for the in depth reply! You have given me a good starting point in which to attack this. I have up voted, but I am new here so it will not accept it at this time. I will wait for any more replies before marking as the answer. Thanks again! – MattCash Oct 15 '15 at 16:04
  • I went with the FileSystemWatcher as a class approach. This is pretty much what the team was doing before; this seems to be a little more manged than coding a thread to go like at the specified file, read it, see if the test has been changed, and then act anyways. Thanks again. – MattCash Oct 15 '15 at 19:04
  • No problem. I'm glad I could help! If your requirements change you can always investigate one of the other methods as well. :) – Matthew Sanders Oct 15 '15 at 19:12