概要
开发人员可以使用“Microsoft Office 自动化”来构建利用 Office 产品内置的功能和特性的自定义解决方案。 虽然这样的编程开发可以在客户端系统上相对容易地实现,可是,如果要通过服务器端代码(例如,Microsoft Active Server Pages (ASP)、ASP.NET、DCOM 或 Windows NT 服务)进行“自动化”,就会发生许多复杂情况。
本文讨论了开发人员可能会面临的各种复杂情况。 本文还提供了可以提高性能的“自动化”替代方法。 但开发人员应了解,本文所提供的解决方案仅供参考。 Microsoft 建议不要进行服务器端“Office 自动化”,也不为此提供支持。
注意在此上下文中,认为 Microsoft 2007 Office 系统驱动程序和 2010 Access 数据库引擎属于 Microsoft Office 组件。 “服务器端”一词也适用于在 Windows 工作站上运行的代码,前提是该代码从所登录用户的交互式站以外的 Windows 工作站运行。 例如,由 SYSTEM 帐户下的“任务计划程序”启动的代码运行的环境与“服务器端”ASP 或 DCOM 代码运行的环境是相同的。 因此会发生很多本文所述的问题。 有关 Windows 工作站和 COM 的更多信息,请参见“更多信息”和“参考”这两部分。
更多信息
Microsoft Office 所有当前版本的设计、测试和配置都是为在客户端工作站上作为最终用户产品运行而完成的。 它们假定存在一个交互式桌面和用户配置文件, 而且不提供满足为以无人参与方式运行而设计的服务器端组件的需要所必需的重入或安全性级别。
Microsoft 目前建议不要从任何无人参与的、非交互式客户端应用程序或组件(包括 ASP、ASP.NET、DCOM 和 NT Service)中进行 Microsoft Office 应用程序的“自动化”,也不为此提供支持,因为 Office 在这种环境中运行时可能会出现不稳定的现象并且/或者会死锁。
如果你正在生成要在服务器端上下文中运行的解决方案,应尝试使用在无人参与执行时设置为安全的组件。 或者,你应尝试找到允许在客户端运行至少一部分代码的替代方法。 如果你从服务器端解决方案使用 Office 应用程序,应用程序可能会缺少成功运行所需的许多必要功能。 此外,你的整个解决方案的稳定性可能存在风险。
使用服务器端 Office 自动化的问题
尝试在服务器端解决方案中使用 Office 的开发人员需要了解 Office 的表现因环境而与预期不同的五个主要问题。 要成功运行代码,必须要解决这些问题,而且需要尽可能减少它们的影响。 构建应用程序时,请仔细考虑这些问题。 一个解决方案无法解决所有问题。 不同设计要求你按不同方式设置元素的优先级。
- 用户身份: Office 应用程序在运行时会假定存在一个用户身份,即使“自动化”启动应用程序时也是如此。 应用程序尝试根据用户注册表配置单元中的设置为启动应用程序的用户初始化工具栏、菜单、选项、打印机和一些加载项。 许多服务在没有用户身份的帐户(例如 SYSTEM 帐户或 IWAM_[服务器名称] 帐户)下运行。 因此,Office 在启动时可能无法正确初始化。 在此情况下,Office 会返回有关 CreateObject 函数或 CoCreateInstance 函数的错误。 如果没有任何用户身份,即使 Office 应用程序可以启动,其他函数可能也无法正确运行。
- 与桌面的交互性: Office 应用程序假设它们在交互式桌面下运行。 在某些情况下,可能需要将应用程序设置为对某些自动化函数可见,以使其正确运行。 如果发生意外错误,或者需要一个未指定的参数才能完成某项功能,根据设计,Office 会用一个模式对话框提示用户,询问用户要进行什么操作。非交互式桌面上的模式对话框无法取消。 这就导致该线程无限期地停止响应(挂起)。 虽然有些代码编写的经验做法有助于减少发生这种情况的可能性,但还是无法做到完全防止。 正是这种情况使得从服务器端环境运行 Office 应用程序带有风险,而且不受支持。
- 重入和可伸缩性: 服务器端组件需要是具有较高可重入性的多线程 COM 组件,这些组件在有多个客户端时开销最少而吞吐量较高。 Office 应用程序在几乎所有方面都正好相反。 Office 应用程序是非重入的、基于 STA 的“自动化”服务器,是为给一个客户端提供多种多样但占用资源较多的功能而设计的。 与服务器端应用程序相比,应用程序提供较少的可伸缩性。 此外,应用程序对重要的元素(例如内存)有固定限制。 这些限制无法通过配置进行更改。 更重要的是,应用程序使用全局资源,例如内存映射文件、全局加载项或模板以及共享自动化服务器。 这样会限制可以同时运行的实例数量,如果在多客户端环境下配置应用程序,可能会导致竞争条件。 开发人员如果计划同时运行多个任意“Office 应用程序”的实例,就需要考虑“后台处理”或序列化对“Office 应用程序”的访问,以避免可能出现的死锁或数据损坏。
- 复原性和稳定性: Office 2000、Office XP、Office 2003 和 Office 2007 使用 Microsoft Windows 安装程序 (MSI) 技术,以使最终用户在进行安装和自行修复时更加容易。 MSI 引入了“首次使用时安装”的概念。 这样可以在运行时为系统动态安装或配置功能,大多数情况下是为特定用户进行安装。 在服务器端环境中,这会既降低性能,又增加出现要求用户同意安装或提供安装盘的对话框的可能性。 虽然此设计旨在增强 Office 作为最终用户产品的复原性,但 Office 实现 MSI 功能在服务器端环境中还是会对生产力带来不利影响。 此外,Office 在服务器端运行时,Office 的稳定性通常无法得到保障,因为它尚未为这样使用而进行设计或测试。 在网络服务器上使用 Office 作为服务组件可能会降低这台计算机的稳定性,进而降低整个网络的稳定性。
- 服务器端安全性: Office 应用程序从不适合在服务器端使用。 因此,Office 应用程序不会考虑分布式组件面临的安全问题。 Office 不会对传入的请求进行身份验证。 Office 也不会防止你无意中启动另一台可能会运行宏的服务器或从服务器端代码中运行宏。 不要打开从匿名网站上载到服务器上的文件。 基于上一次设置的安全性设置,服务器可能会在具有全部特权的 Administrator 或 System 上下文下运行宏,并危及你的网络的安全。 另外,Office 使用很多客户端组件(例如,Simple MAPI、WinInet、MSDAIPP),它们会缓存客户端身份验证信息以加快处理速度。 如果在服务器端自动化 Office,一个实例的作用可能超过一个客户端。 如果为该会话缓存了身份验证信息,一个客户端可以使用另一个客户端的缓存凭据。 因此,客户端可以通过模仿另一个用户获取非授权的访问权限。
除了技术问题之外,还必须考虑许可问题。 目前的许可原则禁止在服务器上使用“Office 应用程序”为客户端请求提供服务,除非那些客户端自己具有 Office 的许可副本。 《最终用户许可协议》(EULA) 没有涉及使用服务器端“自动化”向未经许可的工作站提供 Office 功能的情况。
除了这些问题之外,尝试在服务器端自动化 Office 可能会发生以下常见问题之一:
- CreateObject 函数和 CoCreateInstance 函数返回以下运行时错误消息之一,而且无法启动进行自动化。
消息 1
Run-time error '429': ActiveX component cannot create object
消息 2
Run-time error '70': Permission denied
消息 3
CO_E_SERVER_EXEC_FAILURE (0x80080005): Server execution failed
消息 4
E_ACCESSDENIED (0x80070005): Access denied
- 打开 Office 文档时,可能会收到下面的错误消息:
消息 1
Run-time error '5981' (0x800A175D): Could not open macro storage
消息 2
Run-time error '1004': Method '~' of object '~' failed
- CreateObject 函数和 CoCreateInstance 函数停止响应且永不停止,或花费很长时间才返回。 在一些服务器上,创建速度很快,但 Windows 事件日志中显示 1004 错误,指示应用程序已停止。
- 某些函数意外失败或无限停止响应,因为出现了用户警告或需要用户注意的其他对话框。
- 运行多个请求或压力测试可能导致在创建或终止 Office 应用程序时代码失败、停止响应或崩溃。 出现这种情况时,进程会在内存中保持运行状态且无法终止,或者正在自动化的应用程序的所有实例都从该点开始失败。
除了此处列出的问题或信息之外,还可能出现一些其他问题和信息,但这些问题通常作为本文前面列出的五个问题的结果出现。
服务器端自动化的替代方法
Microsoft 极力建议开发人员在需要开发服务器端解决方案时寻找“Office 自动化”的备选方案。 由于 Office 设计上的局限性,更改 Office 配置不足以解决所有的问题。 Microsoft 提供了很多强烈推荐的备选方案,这些方案不需要在服务器端安装 Office,而且可以比“自动化”更高效、更迅速地执行大多数常规任务。 在将 Office 作为您项目中的服务器端组件之前,请先考虑备选方案。
大多数服务器端“自动化”任务包括创建或编辑文档。 Office 2007 支持新的 Open XML 文件格式,此格式允许开发人员在服务器端创建、编辑、读取和转换文件内容。 这些文件格式在 Microsoft .NET 3.x Framework 中使用 System.IO.Package.IO 命名空间编辑 Office 文件,而无需使用 Office 客户端应用程序本身。 从服务处理对 Office 文件的更改时建议和支持使用此方法。
Open XML 文件格式为公用标准。
Microsoft 提供一个 SDK 用于从 .NET 3.x Framework 操作 Open XML 文件格式。 有关 SDK 和如何使用 SDK 创建或编辑 Open XML 文件的更多信息,请访问以下 Microsoft Developer Network (MSDN) 网站:
使用 Open XML 对象模型操作 Word 2007 文件(第 1 部分,共 3 部分)
使用 Open XML 对象模型操作 Word 2007 文件(第 2 部分,共 3 部分)
使用 Open XML 对象模型操作 Word 2007 文件(第 3 部分,共 3 部分)
使用 Open XML 对象模型操作 Excel 2007 和 PowerPoint 2007 文件(第 1 部分,共 2 部分)
使用 Open XML 对象模型操作 Excel 2007 和 PowerPoint 2007 文件(第 2 部分,共 2 部分)
使用 Open XML 对象模型构建服务器端文档生成解决方案(第 1 部分,共 2 部分)
使用 Open XML 对象模型构建服务器端文档生成解决方案(第 2 部分,共 2 部分)
从 ASP 或 ASP.NET 流式传输 Open XML 文件时,必须为流式传输的内容提供正确的多目的 Internet 邮件扩展协议 (MIME) 类型。 有关适用于 Office 2007 文件的 MIME 类型的列表,请访问以下网站:
适用于 HTTP 内容流的 Office 2007 文件格式 MIME 类型
如果你仅面向低于 Office 2007 的客户端,且无需在解决方案中使用 Open XML,可以使用其他非二进制 Office 文件格式,例如 HTML、XML 和 RTF。 随后你可以通过使用 MIME 类型将这些文件流式传输到客户端,以使生成的文本显示在 Office 中。 可以编辑和保存文档,甚至可以通过在服务器上使用 ASP 将文档返回到服务器。
有关这些主题中的任意一个以及说明如何实现它们的示例的更多信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
198703 如何从客户端 VBScript 自动化 Excel
278973 ExcelADO 演示如何使用 ADO 读写 Excel 工作簿中的数据
286023 如何从 Internet Explorer 中将 VB ActiveX 组件用于 Word 自动化
如果你的业务需要在客户端创建 Office 97、Office 2000、Office XP 和 Office 2003 二进制文件格式,第三方供应商可以提供可帮助你的组件。 Microsoft 不提供这类组件,你需要自己构建解决方案或从第三方供应商处购买一个解决方案。 市场上有很多不同的第三方产品。 你应当调查每个解决方案,以选择最能满足你的业务需要的供应商。
如果你要构建可直接编辑 Office 97、Office 2000、Office XP 和 Office 2003 二进制文件格式的解决方案,你可以根据 Microsoft 开放规范承诺书 (OSP) 的条款免费获取文件格式规范。 不对文档或你创建的产品提供任何技术支持,但可提供文档。
服务器端解决方案还可能要允许用户上载文件,然后使服务器呈现该文件,以便在 Web 或其他媒体上查看。 Microsoft 当前正致力于提供这类功能,并在 Microsoft Excel Services 中提供了此功能的较低版本。
Excel Services 是一个新的服务器技术,随附在 Microsoft Office SharePoint Server 2007 中,可用于在 Office SharePoint Server 2007 上加载、计算和显示 Excel 工作簿。 有关 Excel Services 的更多信息,请访问下面的 Microsoft Developer Network (MSDN) 网站:
演练: 使用 Excel Web Services 开发自定义应用程序
通过使用 Excel Services 和 Office Open XML 格式创建业务应用程序
Word Automation Services 是 SharePoint Server 2010 中的新服务应用程序。 Word Automation Services 提供在服务器端无人参与将文档转换为 Microsoft Word 客户端应用程序支持的格式。
你需要评估本文所述的哪种方法适合你的需要,以及如何才能最好地部署你的解决方案。 本文提供的信息不保证能够解决所有客户端的所有问题。 建议你最好在部署解决方案之前全面测试解决方案。