0

我有一个 Windows 服务,我想定期执行一个外部程序。我目前正在以通常的方式执行此操作

Process program = Process.Start(@"C:\mpewatch\db_parameters\DBParameters.exe");

这似乎不起作用。我正在从我的服务OnStart处理程序中启动的单独线程执行此操作。这有什么概念问题吗?不能从这样的服务执行外部程序吗?

4

3 回答 3

4

可以从服务执行外部程序,但存在安全问题。例如,您的服务可能在对外部程序所在文件夹没有读取权限的帐户下运行,即使您的交互式帐户确实具有该访问权限。

出于测试目的,请尝试将服务配置为在您的交互式帐户下运行。如果程序按预期调用,那么原始帐户的问题是它没有足够的权限来运行程序。

于 2009-08-18T15:15:04.930 回答
1

Windows 服务的另一个关键考虑因素是没有 GUI。从技术上讲,有一个选项允许服务与本地 GUI 交互,但您不会看到它。这是由于以本地系统用户身份运行的服务。

在服务中,任何模式对话框(确定、取消等)都被视为错误。

于 2009-08-18T15:29:26.770 回答
1

你的问题没有说明操作系统。

在 Windows XP 上,您可以通过打开服务控制面板、双击您的服务、选择登录选项卡、将服务配置为作为本地系统运行并选中复选框来配置您的 Windows 服务以与桌面交互。这很简单。您可以尝试使用 Notepad.exe 之类的东西进行测试,看看是否可以使其正常工作。

但是,在 Vista(可能还有 Windows 7)上,您可能不走运。我已经读过 Windows 服务与桌面交互的能力已在 Vista 中删除。我忘记了术语是什么,但基本上服务将在“shell 0”中运行,而用户将占用“shell 1”。用户应用程序将能够使用 WCF 等技术与服务通信,反之亦然,但服务将无法直接与桌面通信。例如,任何弹出的错误框都必须通过交换到“shell 0”来处理。同样,这是基于我几个月前阅读的内容,我没有再去看它。对我来说,我已经构建了我的 Windows 服务,以便通过前端应用程序使用 WCF 进行配置。

抱歉,我没有给你的链接,但如果你的服务最终必须迁移到更新的操作系统(或者你已经在那里),这是需要检查的。

于 2009-08-18T17:55:40.503 回答