Catch tasks from windows task scheduler in a .net app

Question

I have a program that is running in the background, this program has to be notified when a specific windows event is occurring.

I know the name and id for the event and i know how to schedule an action for it in the task scheduler, but here i can only start a new program. I want to call a function in an already running application.

Edit: Solved it like this.

The main program is listening for a TCP connection and from the task scheduler i start another instance of the program with a command line argument. If the program receives this argument it will connect to the main program that performs some action when it receives the connection.

Answer 1

I would have the scheduler start a new process (it could be the same application exe) and have this process set an event that the first process is waiting on. Seems pretty clean to me, especially if you have the scheduler launch the same application (maybe with a special command line).

Answer 2

I second (and upvoted) Murray's comment. Just start a new process that "informs" the existing process of the event occurrence and then dies. If you just need to know that it happened waiting on a global event (windows meaning of the word, not .net's) would seem simple enough.

Answer 3

I'm not sure what you mean by 'windows event' -- there are just so many! You're talking about the task scheduler in the headline, but what you write in your question seems to indicate there's some external change you are looking for with the help of the scheduler. I'll assume it's not a keyboard, mouse or windows event, since that's what GUI frameworks are for.

If the 'glue' application approach isn't elegant or quick enough for you, I'd say dig into Windows Management Instrumentation. Check out this article on MSDN for a starter, and perhaps this one on how to work within VS: if that fails, you may have to descend to the COM Interop level to register your listener.

You haven't stated how your 'background application' is implemented: whether as a normal process with or without a window/GUI, or as a Windows Service, or something more modern. I think WMI listeners work with all of these, but thinking is no substitute for testing (and vice versa!).

I offer this advice with some hesitation: WMI is based on DCOM, which can be a pain in the posterior if you start working across the network, and sometimes within a single machine (running under different user accounts). I'm sure there's a well thought out security model somewhere underneath all the mysterious parameters and configurations!