摘要
开发人员可以使用“Microsoft Office 自动化”来构建利用 Office 产品内置的功能和特性的自定义解决方案。 尽管此类编程开发可以在客户端系统上相对轻松地实现，但如果从服务器端代码（例如 Microsoft Active Server Pages (ASP) 、ASP.NET、DCOM 或 Windows NT 服务）进行自动化，则可能会出现许多复杂情况。
本文讨论开发人员可能面临的复杂问题。 本文讨论了开发人员可能会面临的各种复杂情况。 本文还提供了可以提高性能的“自动化”替代方法。 但开发人员应了解，本文所提供的解决方案仅供参考。
注意: 在此上下文中，Access 数据库引擎可再发行组件和 Access 运行时被视为 Microsoft Office 组件。 “服务器端”一词也适用于在 Windows 工作站上运行的代码，前提是该代码从所登录用户的交互式站以外的 Windows 工作站运行。 例如，由 SYSTEM 帐户下的“任务计划程序”启动的代码运行的环境与“服务器端”ASP 或 DCOM 代码运行的环境是相同的。 因此会发生很多本文所述的问题。 有关 Windows 工作站和 COM 的更多信息，请参见“更多信息”和“参考”这两部分。
更多信息
所有当前版本的 Microsoft Office 都经过设计、测试和配置，以在客户端工作站上作为最终用户产品运行。 它们假定使用交互式桌面和用户配置文件。 它们不提供满足设计为无人参与运行的服务器端组件的需求所需的重新进入级别或安全性。
Microsoft 目前不建议也不支持从任何无人参与的非交互式客户端应用程序或组件 (（包括 ASP、ASP.NET、DCOM 和 NT Services) ）自动化 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 也不会防止你无意中启动另一台可能会运行宏的服务器或从服务器端代码中运行宏。 不要打开从匿名网站上传到服务器的文件。 根据上次设置的安全设置，服务器可以使用完全权限在管理员或系统上下文下运行宏，因此可能会破坏你的网络。 另外，Office 使用很多客户端组件（例如，Simple MAPI、WinInet、MSDAIPP），它们会缓存客户端身份验证信息以加快处理速度。 如果在服务器端自动化 Office，一个实例的作用可能超过一个客户端。 如果为该会话缓存了身份验证信息，一个客户端可以使用另一个客户端的缓存凭据。 因此，客户端可以通过模仿另一个用户获取非授权的访问权限。
除了技术问题之外，还必须考虑许可问题。 目前的许可原则禁止在服务器上使用“Office 应用程序”为客户端请求提供服务，除非那些客户端自己具有 Office 的许可副本。 《最终用户许可协议》(EULA) 没有涉及使用服务器端“自动化”向未经许可的工作站提供 Office 功能的情况。
除这些问题外，尝试自动执行 Office 服务器端时，还可能出现以下常见错误之一：
-
CreateObject 函数和 CoCreateInstance 函数返回以下运行时错误消息之一，而且无法启动进行自动化。
消息 1
运行时错误“429”：ActiveX 组件无法创建对象
消息 2
运行时错误“70”：权限被拒绝
消息 3
CO_E_SERVER_EXEC_FAILURE (0x80080005): Server execution failed
消息 4
E_ACCESSDENIED (0x80070005): Access denied
-
打开 Office 文档时，会收到以下错误消息之一。
消息 1
运行时错误“5981” (0x800A175D) ：无法打开宏存储
消息 2
运行时错误“1004”：对象“~”的方法“~”失败
-
CreateObject 函数和 CoCreateInstance 函数停止响应且永不停止，或花费很长时间才返回。 在一些服务器上，创建速度很快，但 Windows 事件日志中显示 1004 错误，指示应用程序已停止。
-
某些函数意外失败或无限停止响应，因为出现了用户警告或需要用户注意的其他对话框。
-
运行多个请求或压力测试可能导致在创建或终止 Office 应用程序时代码失败、停止响应或崩溃。 出现这种情况时，进程会在内存中保持运行状态且无法终止，或者正在自动化的应用程序的所有实例都从该点开始失败。
除了此处列出的问题或消息之外，还可能出现其他问题或消息，但这些问题通常是由于本文前面列出的五个main问题导致的。
服务器端自动化的替代方法
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 对象模型生成 Server-Side 文档生成解决方案 (第 1 部分，共 2 部分)
使用 Open XML 对象模型生成 Server-Side 文档生成解决方案 (第 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
如何使用 ASP 中的 ADO 查询和更新 Excel 数据
286023 如何使用 VB ActiveX 组件从 Internet Explorer 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 开发人员网络 (MSDN) 网站：
演练：使用 Excel Web Services 开发自定义应用程序
使用 Excel Services 和 Office Open XML 格式创建业务应用程序 Word Automation Services 是 SharePoint Server 2010 中的新服务应用程序。 Word Automation Services 提供在服务器端无人参与将文档转换为 Microsoft Word 客户端应用程序支持的格式。
Word Automation Services 简介 你需要评估本文所述的哪种方法适合你的需要，以及如何才能最好地部署你的解决方案。 本文提供的信息不保证能够解决所有客户端的所有问题。 建议你最好在部署解决方案之前全面测试解决方案。
