无法访问excel文件答案

【问题标题】：Cannot access excel file无法访问excel文件
【发布时间】：2012-12-26 07:30:49
【问题描述】：

我正在开发 Windows 服务，生成报告。该报告有一个模板。这个模板是在一个 excel 文件中准备的。该文件被复制到输出文件夹。

在开发过程中，我像控制台应用程序一样启动了该服务，并且访问该文件没有问题。

然后我准备了一个服务安装程序。该服务安装在Local System 帐户下。所以这个excel模板文件被标记为content，并与可执行文件一起复制到安装目录。

但是当服务启动时，excel 似乎无法访问该文件。该服务安装到c:\Program Files (x86)\Our Company\Service Name\。目标操作系统是 Windows Server 2008。在测试时我使用的是 Windows 7 并遇到了同样的问题。

我使用以下代码访问excel。

using Excel = Microsoft.Office.Interop.Excel;    
//...
Excel.Application xlApp = new Microsoft.Office.Interop.Excel.Application();
//the following line throws an exception
Excel.Workbook xlWorkBook = xlApp.Workbooks.Open(@"path");

我还尝试将 excel 模板文件复制到某个临时目录（服务有权在其中写入 - 已测试）并尝试从那里打开它，但没有成功（虽然此变体在控制台应用程序）。

错误信息是：

Microsoft Office Excel 无法访问文件 /path/。有几个可能的原因：
1. The file name or path does not exist.
2. The file is being used by another program.
3. The workbook you are trying to save has the same name as a currently open workbook.

如何让windows服务访问这个excel模板文件？还是有其他选择？

【问题讨论】：

如果您让服务使用管理员帐户（例如您自己的帐户）而不是本地系统，它可以工作吗？
@ShadowWizard 让我试试..
@ShadowWizard 我在 mmc 服务控制台中将其更改为在我的帐户下运行。没有任何改变。
嗯.. 所以这不是权限问题。奇怪！
@ShadowWizard 在 mmc 控制台中更改服务帐户时我可能会出错吗？

标签： c# excel windows-services interop

【解决方案1】：

要使用本地系统帐户在用户服务下安全运行 Office 应用程序（Excel 和其他），您必须了解两个重要事项： 1) 在 Windows Server 2008/2008 R2 中，您必须手动创建两个文件夹： C:\Windows\system32\config\systemprofile\desktop
C:\Windows\SysWow64\config\systemprofile\desktop（仅适用于 x64 版本）如果没有此文件夹，您将无法从本地系统帐户更正运行办公应用程序

2) 如果您的服务配置为没有桌面交互，那么在第一次启动 Office 应用程序（例如 Excel）时冻结用户凭据对话框 - 在此模式下您看不到此窗口 - 要解决此问题，请启用桌面交互，切换到服务后的办公室窗口运行它并手动输入凭据。

其他信息there（使用谷歌翻译阅读）。

【讨论】：

我在使用 Windows 7 时遇到了这个问题。添加路径 C:\Windows\system32\config\systemprofile\desktop 解决了这个问题。非常感谢您的帖子。
感谢您的解决方案。它修复了 Windows server 2012 中的相同问题。
创建两个文件夹为我解决了 Windows 8.1 的问题
尽管有上述警告，但我认为，如果您正在执行特定任务（已经过测试的任务，未以一般方式使用它），并且某些任务只有 Excel 会执行（有没有第三方库可以像 Excel 那样高效地操作大文件）它可以可靠地运行。
Thx，即使我的服务以特定用户身份运行，而不是使用最新的 Windows 10 创意者更新的本地系统，也必须创建这 2 个文件夹。

【解决方案2】：

有一篇详细的 MS 知识库文章，标题为 Considerations for server-side Automation of Office。一些关键摘录：

用户身份：Office 应用程序在运行应用程序时假定用户身份，即使自动化启动应用程序。应用程序尝试初始化工具栏、菜单、选项、打印机和一些基于用户设置的加载项启动应用程序的用户的注册表配置单元。许多服务在没有用户配置文件的帐户下运行（例如 SYSTEM 帐户或 IWAM_[servername] 帐户）。因此，Office 可能不会启动时正确初始化。在这种情况下，Office 返回一个 CreateObject 函数或 CoCreateInstance 函数上的错误。即使可以启动 Office 应用程序，其他功能也可能无法启动如果不存在用户配置文件，则可以正常工作。

与桌面的交互性：Office 应用程序假定它们在交互式桌面下运行。在一些在某些情况下，可能需要使应用程序可见自动化功能正常工作。如果发生意外错误，或者如果需要一个未指定的参数来完成一个功能， Office 旨在通过模式对话框提示用户询问用户用户想要做什么。一个模态对话框无法关闭非交互式桌面。因此，该线程无限期停止响应（挂起）。虽然某些编码实践可以帮助减少此问题的可能性，这些实践不能完全避免这个问题。 仅这一点就使从服务器端环境运行 Office 应用程序存在风险，并且不受支持。

显然，正如 cmets 中所指出的，使用 SYSTEM 帐户是错误的。您需要在具有用户配置文件的帐户下运行该服务。

但即使你解决了这个问题，另一个要点也会杀死你。 Office 应用程序确实假设它们在交互式桌面下运行。我的建议是放弃尝试通过服务自动化 Office。改用 Aspose 之类的库。或者在交互式桌面上运行该进程。

【讨论】：

大卫，非常感谢您提供这个很棒的链接和所有信息。我现在必须考虑替代方案。

【解决方案3】：

我刚遇到同样的问题。

我制作了一个 .bat 文件，我在其中调用了 .exe 文件。

最后，我从任务调度程序操作中调用了 .bat 文件。

效果很好。

【讨论】：