Word Interop 无法在计划任务中工作

发布于 2024-07-28 23:56:57 字数 696 浏览 8 评论 0原文

我目前正在开发一个脚本,该脚本获取 Word 文档,在 Word 中打开它,然后将 Word 文件打印为 PDF。 在我的机器或服务器上手动运行时一切都很好。 当我尝试将其作为计划任务运行时,问题就出现了。

要求之一是这应该每晚进行,无需任何干预。 当我设置计划任务来执行此操作并将安全选项设置为“仅在用户登录时运行”时,一切正常。 问题是,这必须在有人登录或无人登录的情况下运行。 如果我将任务设置为“无论用户是否登录都运行”,脚本将在以下行失败:

wordDoc = MSWord.Documents.Open(ref fileToConvert, ref refFalse, ref refTrue, 
                                ref RN, ref RN, ref RN, ref RN, ref RN,
                                ref RN, ref RN, ref RN, ref RN, ref RN,
                                ref RN, ref RN, ref RN);

MSWord.Documents.Open() 有效,但返回 null。

此任务在带有 Office 2007 的 Windows Server 2008 上运行。

为此我应该采取另一种方法吗?

I'm currently developing a script that takes a Word document, opens it up in Word, and then prints the Word file as a PDF. Everything works great when run manually either on my machine or the server. The problem comes in when I attempt to run it as a scheduled task.

One of the requirements is that this should be done nightly without any intervention. When I set up a schedule task to do this and set the security options to "Run only when user is logged on" everything works fine. Problem is, this has to be run with or without someone being logged on. If I set the task to "Run whether user is logged on or not", the script fails on the following line:

wordDoc = MSWord.Documents.Open(ref fileToConvert, ref refFalse, ref refTrue, 
                                ref RN, ref RN, ref RN, ref RN, ref RN,
                                ref RN, ref RN, ref RN, ref RN, ref RN,
                                ref RN, ref RN, ref RN);

MSWord.Documents.Open() works, but returns null.

This task is running on Windows Server 2008 with Office 2007.

Is there another approach I should be taking for this?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

美胚控场 2024-08-04 23:56:57

我在 Windows Server 2008 下从 Windows 服务自动化 Office 时遇到了问题,即使在 Windows Server 2003 下工作正常。该问题也出现在 Open 调用中,尽管它实际上引发了异常,而不是简单地返回 null。 不管怎样,你可能想尝试这个......

我尝试遵循 H Okawa 在 这个 MSDN 线程,它似乎有效。 这很奇怪,但值得称赞的是小川先生发现了它。

“Okawa Hack”摘要:为系统配置文件创建一个桌面文件夹,例如

C:\Windows\SysWOW64\config\systemprofile\Desktop

C:\Windows\System32\ config\systemprofile\Desktop

...取决于您是否有 64 位 Windows。

此外,该文件夹需要“驱动”Office 的任何用户的写入权限。

[编辑:更正链接 URL]

I've had problems automating Office from a Windows Service under Windows Server 2008, even though that works fine under Windows Server 2003. The problem also occurs at the Open call, though it actually raises an exception rather than simply returning null. Anyway, you might want to try this...

I tried following the advice given by H Ogawa in this MSDN thread, and it seemed to work. It's bizarre, but kudos to Mr. Ogawa for discovering it.

Summary of the 'Ogawa Hack': create a desktop folder for the system profile, as either

C:\Windows\SysWOW64\config\systemprofile\Desktop, or

C:\Windows\System32\config\systemprofile\Desktop

...depending on whether you have 64-bit Windows.

Also, the folder needs write permission for whatever user is "driving" Office.

[Edit: corrected link URL]

电影里的梦 2024-08-04 23:56:57

我相信很多人都尝试过做一些与您正在尝试的事情相似的事情,但都失败了。 有很多关于无法在类似服务器模式(无人值守等)下运行任何基于办公室互操作的解决方案的讨论。

请参阅此处这里

我知道这可能不是您正在寻找的答案,但它仍然是如何这是!

I believe that many people have tried to do something close to what you are attempting and failed. There is a lot of chatter about not being able to run any office interop based solutions in a server-like mode (unattended etc).

See here and here

I know this is probably not the answer you were looking for but it is nevertheless how it is!

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文