在 .net 应用程序中从 Windows 任务计划程序捕获任务
我有一个在后台运行的程序，当发生特定的 Windows 事件时必须通知该程序。
我知道事件的名称和 ID，并且知道如何在任务计划程序中为其安排操作，但在这里我只能启动一个新程序。 我想在已经运行的应用程序中调用一个函数。
编辑：像这样解决它。
主程序正在侦听 TCP 连接，并且从任务调度程序中我使用命令行参数启动该程序的另一个实例。 如果程序接收到此参数，它将连接到主程序，主程序在接收到连接时执行某些操作。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会让调度程序启动一个新进程（它可能是同一个应用程序 exe），并让该进程设置第一个进程正在等待的事件。 对我来说似乎很干净，特别是如果您让调度程序启动相同的应用程序（可能使用特殊的命令行）。
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).
我赞同（并投了赞成票）默里的评论。 只需启动一个新进程，“通知”现有进程事件发生，然后死亡。 如果您只需要知道它是在等待全局事件（该词的 Windows 含义，而不是 .net 的含义）时发生的，那么似乎很简单。
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.
我不确定你所说的“Windows 事件”是什么意思——有太多了！ 您在标题中谈论了任务调度程序，但是您在问题中所写的内容似乎表明您正在调度程序的帮助下寻找一些外部更改。 我假设这不是键盘、鼠标或窗口事件，因为这就是 GUI 框架的用途。
如果“粘合”应用程序方法对您来说不够优雅或不够快，我建议深入研究 Windows管理仪表。 请查看 MSDN 上的这篇文章作为初学者，也许这个关于如何在 VS 中工作的内容：如果是的话如果失败，您可能必须下降到 COM Interop 级别才能注册您的侦听器。
您还没有说明您的“后台应用程序”是如何实现的：无论是作为带或不带窗口/GUI的正常进程，还是作为Windows服务，或者某种更现代。 我认为 WMI 侦听器可以处理所有这些，但思考不能替代测试（反之亦然！）。
我有些犹豫地提出这个建议：WMI 基于 DCOM，这可能是一个痛苦如果您开始通过网络工作，有时在一台机器上（在不同的用户帐户下运行），则后一种情况。 我确信在所有神秘的参数和配置下面有一个经过深思熟虑的安全模型！
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!