概要

开发人员可以使用“Microsoft Office 自动化”来构建利用 Office 产品内置的功能和特性的自定义解决方案。虽然这样的编程开发可以在客户端系统上相对容易地实现，可是，如果要通过服务器端代码（例如，Active Server Page (ASP)、DCOM 或 NT Service）进行“自动化”，就会发生许多复杂情况。

本文介绍开发人员可能会面对的这些复杂情况，提供可以提高性能的“自动化”备选方案，并提出在必须要进行服务器端“自动化”的情况下配置 Office 的方法。不过，开发人员应该知道，下面提供的建议仅供参考。Microsoft 建议不要进行服务器端“Office 自动化”，也不为此提供支持。

注意：在此上下文中，“服务器端”一词也适用于在 Microsoft Windows NT 或 Microsoft Windows 2000 工作站上运行的代码，前提是该代码从所登录用户的交互式站以外的 WinStation 运行。例如，由 SYSTEM 帐户下的“任务计划程序”启动的代码运行的环境与“服务器端”ASP 或 DCOM 代码运行的环境是相同的，因此会遇到许多相同的问题。有关 WinStations 和 COM 的更多信息，请参见“更多信息”和“参考”等部分。


Microsoft Office 所有当前版本的设计、测试和配置都是为在客户端工作站上作为最终用户产品运行而完成的。它们假定存在一个交互式桌面和用户配置文件，而且不提供满足为以无人值守方式运行而设计的服务器端组件的需要所必需的重入或安全性的级别。

Microsoft 目前建议不要从任何无人值守的、非交互式客户端应用程序或组件（包括 ASP、DCOM 和 NT Service）中进行 Microsoft Office 应用程序的“自动化”，也不为此提供支持，因为 Office 在这种环境中运行时可能会出现不稳定的现象并且/或者会死锁。

如果您要构建在服务器端上下文中运行的解决方案，应尽可能尝试使用对于以无人值守方式执行很安全的组件，或找到至少允许一部分代码在客户端运行的备选方案。如果您选择从服务器端解决方案中运行 Office 应用程序，将发现这样会缺少成功运行所必需的许多功能，而且整体解决方案的稳定性会有风险。

使用服务器端“Office 自动化”时的问题

尝试在服务器端解决方案中使用 Office 的开发人员需要了解 Office 的表现因环境而与预期不同的五个主要问题。若要成功运行您的代码，就需要解决这些问题，而且需要尽可能减少它们的影响。您在生成应用程序时，要仔细考虑这些问题，因为没有任何一种解决方案能解决所有这些问题，不同的设计要求您优先考虑不同的元素。

       1. 用户身份：Office 应用程序在运行时会假定存在一个用户身份，即使在它们由“自动化”启动时也是如此。它们尝试根据用户注册表配置单元中的设置为启动应用程序的用户初始化工具栏、菜单、选项、打印机和一些加载项。许多服务会在没有用户配置文件的帐户（例如，SYSTEM 或 IWAM_[服务器名] 帐户）下运行，因此，Office 可能无法在启动时进行正确的初始化，进而返回一个有关 CreateObject 或 CoCreateInstance 的错误。即使能够在没有用户配置文件的情况下启动 Office 应用程序，其他功能也可能无法正常工作。如果您计划从某个服务进行“Office 自动化”，需要配置您的代码或 Office，以便它使用某个已加载的用户配置文件来运行。

       2. 与桌面的交互性：Office 应用程序假定它们在某个交互式桌面下运行，在有些情况下，可能需要让用户看到它们以便某些“自动化”功能正常运行。如果发生意外错误，或者需要一个未指定的参数才能完成某项功能，根据设计，Office 会用一个模式对话框提示用户，询问用户要进行什么操作。非交互式桌面上的模式对话框是无法取消的，这就导致该线程无限期地停止响应（挂起）。虽然有些代码编写的经验做法有助于减少发生这种情况的可能性，但还是无法做到完全防止。正是这种情况使得从服务器端环境运行 Office 应用程序带有风险，而且不受支持。

      3. 重入和可伸缩性：服务器端组件需要是具有较高可重入性的多线程 COM 组件，这些组件在有多个客户端时开销最少而吞吐量较高。Office 应用程序在几乎所有方面都正好相反。它们是非重入的、基于 STA 的“自动化”服务器，是为给一个客户端提供多种多样但占用资源较多的功能而设计的。它们作为服务器端解决方案提供不了多少可伸缩性，而且对于重要元素有固定的限制，例如，对于内存，无法通过配置进行更改。更重要的是，它们要使用全局性资源（例如，映射到内存的文件、全局加载项或模板，以及共享的“自动化”服务器），这样可能会限制能够并发运行的实例的数量，而且，如果它们是在多客户端环境中配置的，还可能导致争用的情况。开发人员如果计划同时运行多个任意“Office 应用程序”的实例，就需要考虑“后台处理”或序列化对“Office 应用程序”的访问，以避免可能出现的死锁或数据损坏。

     4. 复原性和稳定性：Office 2000、Office XP 和 Office 2003 使用 Microsoft Windows 安装程序 (MSI) 技术，以使最终用户在进行安装和自行修复时更加容易。MSI 推出了“首次使用时安装”的概念，允许在运行时动态安装或配置功能（针对系统，或者更多地是针对特定用户）。在服务器端环境中，这会既降低性能，又增加出现要求用户同意安装或提供相应安装盘的对话框的可能性。虽然此设计旨在增强 Office 作为最终用户产品的复原性，但 Office 实现 MSI 功能在服务器端环境中还是会对生产力带来不利影响。此外，在服务器端运行时，Office 的稳定性通常无法得到保障，因为它尚未为这样使用而进行设计或测试。在网络服务器上使用 Office 作为服务组件可能会降低这台计算机的稳定性，进而降低您的网络作为一个整体的稳定性。如果您计划在服务器端自动运行 Office，请尝试将该程序隔离到一台专用计算机上，该计算机不能影响重要功能，而且在需要时可以重新启动。

     5. 服务器端安全性：Office 应用程序从来都不是为在服务器端使用而准备的，因此，请不要考虑分布式组件所面临的安全性问题。Office 不对传入的请求进行身份验证，而且不会保护您免受无意中从服务器端代码中运行宏或启动另一台可能会运行宏的服务器的损害。不要打开从匿名 Web 上传到服务器的文件！基于上一次设置的安全性设置，服务器可能会在具有全部权限的 Administrator 或 System 上下文下运行宏，并危及您的网络的安全！另外，Office 使用很多客户端组件（例如，Simple MAPI、WinInet、MSDAIPP），它们会缓存客户端身份验证信息以加快处理速度。如果在服务器端进行 Office 自动化，则一个实例可能为多个客户端提供服务，而且由于已经为该会话缓存了身份验证信息，就有可能出现这样的情况：一个客户端可以使用另一个客户端的缓存凭据，从而通过模拟其他用户获得未经授予的访问权限。

除了要考虑技术问题以外，您还必须考虑这样一种设计在许可方面的可行性。目前的许可原则禁止在服务器上使用“Office 应用程序”为客户端请求提供服务，除非那些客户端自己具有 Office 的许可副本。最终用户许可协议 (EULA) 没有涉及使用服务器端“自动化”向未经许可的工作站提供 Office 功能的情况。

除了这些比较大的问题以外，许多客户还发现在不修改其 Office 默认安装的情况下，尝试进行服务器端自动化时可能遇到下列常见错误之一：

• CreateObject/CoCreateInstance 返回以下运行时错误信息之一，而且无法为“自动化”启动：

在 Microsoft Visual Basic (VB) 或 ASP 中：
Run-time error '429':ActiveX component cannot create object
- 或 -
Run-time error '70':Permission denied
在 Microsoft Visual C 或 Visual C++ 中：
CO_E_SERVER_EXEC_FAILURE (0x80080005):Server execution failed
- 或 -
E_ACCESSDENIED (0x80070005):Access denied
出现这些错误是因为服务器端代码在没有用户配置文件的情况下运行，或者为启动上下文指定的用户身份没有正确的 DCOM 权限。


• 打开 Office 文档会导致下列错误之一：
Run-time error '5981' (0x800A175D):Could not open macro storage
- 或 -
Run-time error '1004':Method '~' of object '~' failed
通常，出现这种情况是由于无法初始化 VBA，而无法初始化的原因是权限不足或缺少 VBA 组件注册，当用户从没有用户配置文件的帐户中运行代码（问题 1）并且用户标记不包含“交互式 SID”（问题 2）时，这两种原因都很常见。


• CreateObject/CoCreateInstance 挂起并无法完成，或者需要很长时间才能返回。在有些服务器上，创建很快完成，但 Windows (NT) 事件日志中出现 1004 错误。

问题通常是出现一个运行服务器端代码的非交互式桌面的模式对话框（问题 2）。如果出现该对话框的原因是某个 MSI 组件安装有问题（丢失注册表项或文件映像损坏），它会在找不到安装点时提示需要安装 CD，然后执行一个或多个组件的重新安装（问题 4）。

• 某些功能会意外失败或无限期挂起。
在非交互的情况下（问题 2），特定资源（如打印机、映射的驱动器、OLE 嵌入对象和剪贴板）可能变得无法使用，或者它们的状态可能变得不确定。同样，如果没有用户配置文件（问题 1），则网络资源无法使用，而且权限最小。

• 运行多个请求或压力测试可能导致在创建或终止“Office 应用程序”时代码失败、挂起或崩溃。一旦出现这种情况，进程会在内存中保持运行状态且无法终止，或者正在自动化的应用程序的所有实例都从该点开始失败。

由于 Office 应用程序要共享全局性资源（问题 3），所以，需要针对特定的操作（包括启动、关机、打印、导出和 OLE 链接更新（包括任何 DDE 通知）这样的事件）序列化对某个 Office 应用程序的访问。
除了此处列出的问题或消息之外，还可能出现一些其他问题和消息，但它们通常作为前面列出的五个问题的结果出现。为了解决这几种错误，开发人员应该将 Office 的操作环境配置为模拟客户端状态，或者从任何服务器端代码中删除 Office 应用程序并改为使用更稳定的组件（或客户端“自动化”）。

使用服务器端运行自动化的备选方案

Microsoft 强烈建议开发人员在需要开发服务器端解决方案时寻找“Office 自动化”的备选方案。由于 Office 设计上的局限性，更改 Office 配置不足以解决所有的问题。Microsoft 提供了很多备选方案建议，这些方案不需要在服务器端安装 Office，而且可以比“自动化”更高效、更迅速地执行大多数常规任务。在将 Office 作为您的项目中的服务器端组件之前，请先考虑备选方案。

大多数服务器端“自动化”任务包括创建文档。由于 Office 2000 及更高版本支持 HTML 作为本机文档格式，所以大多数文档可以用 HTML 格式创建，在需要时还可以使用可扩展标记语言 (XML) 标记，而且还可以通过使用多用途 Internet 邮件扩展 (MIME) 类型将数据流传输到客户端，以便在 Office 中显示最终文本。文档可以被编辑和保存，甚至在需要时通过在服务器上使用 ASP 即可将文档返回到服务器。对于 Office 的早期版本，使用其他便于操作的文本格式（例如 RTF）可以实现同样的效果。

有些本机二进制格式可以通过使用 Office Web 组件 (OWC) 或 ActiveX 数据对象 (ADO) 来编辑，速度更快，稳定性也更高。不进行“自动化”也可以查看或更改文档属性，通过使用 FrontPage 服务器扩展 (FPSE) 或分布式创作及版本控制 (DAV)，可以进行文件管理和版本控制。如果必须要进行“自动化”，可以将大多数任务卸载到客户端，这样系统的稳定性和可伸缩性都会更高，因为每个用户都在自己的上下文中用自己的设置运行任务。

有关这些主题以及显示如何实现它们的示例的其他信息，请单击下面的文章编号，以查看 Microsoft 知识库中的相应文章：

270906  如何使用 ASP 生成 RTF 文档以将数据流传送到 Microsoft Word
198703  如何从客户端 VBScript 自动化 Excel
199841  如何在 IE 中使用 Excel 以 MIME 类型显示 ASP 结果
224351  Dsofile.exe 允许在不具备 Office 的情况下在 Visual Basic .NET 2003 和 Visual Basic .NET 2002 中编辑 Office 文档属性
244049 如何使用服务器端图表绘制功能来动态生成图表
258187 OWebComp.exe 包含用于 Office 2000 Web 组件的脚本示例
260239 如何在创建具有 Active Server Page 页的 Excel 文件时设置单元格数据的格式
278973 ExcelADO 演示如何在 Excel 工作簿中使用 ADO 来读写数据
286023 如何从 Internet Explorer 中将 VB ActiveX 组件用于 Word 自动化
288130 如何使用 ASP 生成电子表格 XML 以便在客户端显示
317316 INFO：Office 2000 Web 组件在服务器端使用时的限制
有些第三方供应商可能会提供服务器端组件来实现与 Microsoft Office 的集成。 有关这些第三方供应商的其他信息，请访问下面的网站：

Polar
http://www.polarsoftware.com (http://www.polarsoftware.com)
SoftArtisans
http://www.softartisans.com (http://www.softartisans.com)
SyncFusion
http://www.syncfusion.com (http://www.syncfusion.com)
注意： 本文中提到的第三方产品由 Microsoft 以外的其他公司提供。对于这些产品的性能或可靠性，Microsoft 不作任何暗示保证或其他形式的保证。

配置 Office 在服务器端运行

如果没有其他可行的解决方案，并且您决定继续在服务器端进行“Office 自动化”，您需要解决前面列出的许多问题才能在这种环境中成功运行。由于大多数问题都是与配置相关的，所以无法给出一套让“Office 自动化”在所有系统的所有情况下都能在服务器端正常运行的步骤。有些配置设置可能会与其他选项冲突，每种方法都各有利弊。您可能需要不断试验，才会找到最适用于您的环境的方案。

要从服务器端代码中进行“Office 自动化”，一般需要完成以下任务：

  • 设计您的项目以隔离和封装 Office。

  • 给项目编写代码时要预见到问题并寻求能够动态解决这些问题的方法。

  • 给项目提供一个供 Office 使用的特定用户身份和配置文件。

您的项目设计方案要考虑到在尝试使用“Office 自动化”时服务器端安全性和 Office 非重入性方面的问题。将对 Office 的使用限制到某个特定实例，由一个序列化对象（mutex 或自定义的锁定基元）来控制这个实例，或者，利用能够在需要时发出应用程序对象的自定义对象处理程序（或中间装置）来“后台处理”一组控制紧密的实例，但要控制那些需要序列化的方面。Office 假定存在一定数量的状态，所以多个同时执行某些操作（例如，启动、关机、打印，等等）的客户端会导致冲突，而且可能锁死一个或多个调用线程，其现象是：显示一条错误，提示用户参考更多信息，或者拒绝释放所有实例占用的全局性资源。

因此，首先要限制服务器端设计中对“Office 自动化”的使用，并且将进程隔离到一台在需要时可以重新启动的不太重要的计算机上。还要隔离调用上下文，这样，挂起的调用客户端就不会降低必不可少的系统服务的性能。例如，不要使用系统线程直接从 IIS 中进行自动化操作，而是要将代码隔离到在它自己的线程上运行，这样，即使它失败，一般也不会影响 IIS 功能。另外，还要考虑您的设计如何实施安全性和身份验证。由于 Office 不实施服务器端安全性，所以您的代码需要确保只有“受信任”的代码模块（例如，ASP 页、脚本文件，等等）才能创建 Office 应用程序的“自动化”实例并调用其方法，还要确保所有文档在您让 Office 打开它们之前都是安全的。服务器上的 Office 应用程序应该无论何时都以“高”安全性运行。如果您的设计不实施完全性，您的服务器就会面临风险！

一旦设计方案就位，您就应该编写防御性代码，以尝试预防问题发生，并在问题发生时处理错误。您的代码一定要传递可选参数的值，因为缺少的或有冲突的值有时要求 Office 提示用户参考更多信息。在所有功能中使用错误陷阱，正确地处理错误条件，并通过使用可以利用一个自定义设置（在注册表或 INI 文件中）来打开或关闭的日志记录代码来记录这些错误。如果您执行一项可能导致出现独立于 Office 显示的错误对话框的功能（例如，打印可能导致打印机驱动程序在打印机缺纸时显示对话框），就要准备处理可能出现的死锁，方法是通过使用超时或第二线程来监控进程。有关更多信息，请参见 Microsoft 知识库中的以下文章：
259971 如何使用 Visual Basic 关闭 Office 应用程序显示的对话框 使用您的日志记录代码来跟踪问题和调试程序。如果您使用自定义对象池，可以添加性能测试和可伸缩性测试，以监控使用情况并记录影响所有客户端的问题。通过一个中央控制程序，您还可以在需要时终止 Office 的错误实例并随后重新创建它们，以增强总体稳定性。

在程序准备就绪可以部署之后，一定要在服务器上正确配置 Office，以便运行合适的用户上下文。Office 需要用户配置文件，并且必须确保它在加载时有一个配置文件才能成功实现自动化。在服务器端环境中工作时，有三种方法可以做到这一点： • 将“自动化”启动的 Office 应用程序的所有实例都配置为以“交互式”用户的身份运行。
    • 将“自动化”启动的 Office 应用程序的所有实例都配置为以某个特定用户的身份运行。
    • 通过使用 MTS/COM+ 软件包并允许 Office 应用程序继承启动该应用程序的用户的身份，将代码配置为以某个特定用户的身份运行。

第一种方法可以使 Office 同时获得特定桌面的身份和可交互性，它是调试时的最佳选择（因为可以让 Office 可见，并且能够让本地登录的用户看到和记录任何对话框或 GPF 错误）。为了成功运行，这种方法确实会要求交互式用户保持登录状态，所以，它可能不适用于某些情况。有关更多信息，请参见 Microsoft 知识库中的以下文章：
288366  如何将 Office 应用程序配置为在交互式用户帐户下运行
第二种方法会指定一个特定用户，但不允许交互性。Office 会在一个不可见的桌面上的新 WinStation 中以被指定用户的身份启动。这种方法需要进行一些其他配置，以确保加载用户注册表配置单元，因为在默认情况下 COM/DCOM 不会做这一步。该设置对于系统来说是全局性的，所以它可能会与其他程序冲突。有关以这种方式配置 Office 的更多信息，请参见 Microsoft 知识库中的以下文章：

288367 如何将 Office 应用程序配置为在特定用户帐户下运行
第三种方法允许您为特定网站或代码模块指定一个身份，避免为 Office 全局性地设置一个固定身份。只要以前已经为该计算机配置了该身份并且已经加载了注册表配置单元，Office 就会以该身份运行并正确加载。通常，这种方法是最灵活、最可靠的，但是，像前一种方法一样，这种方法也不提供与某个可见桌面的交互性，而且它也需要额外进行一些设置。有关以这种方式配置 Office 的更多信息，请参见以下 Microsoft 知识库中的文章：

288368 如何配置 Office 应用程序以便从 COM+/MTS 程序包自动运行
您需要评估上述哪种方法适合您的需要，以及如何才能最好地部署您的解决方案。此处提供的信息不保证能够解决所有客户端的所有问题。建议您最好在部署之前彻底地进行测试。