Office XP 主互操作程序集入门

项目
10/29/2007

Chris Kunicki

OfficeZealot.com

摘要：学习如何使用 Office XP 主互操作程序集从 Microsoft Visual Studio .NET 代码项目中扩展和自动启用 Office XP 功能。

2002 年 9 月，Microsoft® 发布了 Office XP Primary Interop Assemblies（英文）。通过这些主互操作程序集 (PIA)，解决方案开发人员可以使用 Microsoft .NET Framework 的所有新功能，并以可靠一致的方式访问 Microsoft Office。在本文中，我将介绍 Office XP PIA 的重要性，以及有关如何在您的解决方案中开始使用 Office XP PIA 的基础知识，介绍过程中还会回顾一些重要的 .NET 术语，最后将通过几个示例演示一个自动启用 Microsoft Office 的 .NET 应用程序。

本文并非是对 Office XP PIA 用法的全面分析，您可能也不需要这样的分析。我将在本文中提供一些有用的参考供您浏览。如果您已熟悉 .NET Framework（MSDN 中有详细介绍），便会发现 Office XP PIA 的使用其实比较简单。这是我的个人体会。首先，我安装了 Office XP PIA 并阅读了附带的自述文件，几分钟后，就发现能够在 Microsoft Visual Studio® .NET 中自动启用 Office。这真是太棒了！

提醒读者一下，我不在 Microsoft 工作。因此，尽管我与雷德蒙德（Microsoft 总部所在地）的朋友合作密切，但我和您一样都是局外人。阅读本文时，希望您不要很快把我的某些话当作推销之辞而置之不理。我认为，.NET 对于将来的桌面生产率至关重要，这将给那些质疑或批评桌面系统未来的业界权威当头一棒。

因此，对于现在和过去致力于将 Office 用于解决方案的开发人员而言，探索 .NET 是非常重要的。Microsoft .NET 解决了很多在 Office 开发过程中遇到的问题。例如，对在服务器或 Internet 上部署 Office 解决方案所做的小革新、名为“DLL hell”的问题、代码重复使用性方面的挑战以及 Visual Basic® for Applications (VBA) 的局限性等问题。

此外，现今纯粹基于 Web 浏览器的界面对各种类型的解决方案均存在限制，而且为用户提供的灵活性也很小。Microsoft Office 已成为用户创建内容和分析信息的首选工具。由于 Office 能够为普通用户提供很多方便，因此 Office 将有助于为用户提供超凡的体验，并为下一代 .NET 应用程序（这些应用程序利用基于 Internet 标准的分布式计算和桌面计算机的原始设计和智慧）提供可观的投资回报。

本页内容

为什么是 Office 和 .NET？
简要历史回顾
Office XP PIAs 简介
安装 Office XP PIA
添加引用
示例 1：使用 Word 的拼写检查引擎
示例 2：使用 ADO.NET 数据集，第 2 部分
小结
更多信息

为什么是 Office 和 .NET？

为什么是 Office 和 .NET？让我们重新考虑一下。Microsoft 为何不将 .NET 并入 Office？

Microsoft 在 .NET 上做出了巨大的投入，宣称它是先前开发模型的“接班人”。而 Office 是 Microsoft 计算理念的基石。要使 Office 继续向前发展，它必须建立在 .NET 的新基础之上。那些坚持走老路的少数人对这种变化表示怀疑，但多数人还是对这种进步持欢迎态度，连那些对 .NET 漠不关心的人似乎也转变了看法。多年从事 Microsoft 技术咨询和研究的经验告诉我，只要 Microsoft 下定决心，要在某项重要技术（例如 .NET）上取得成功，业界最终将完全接受这项技术。

那么，这与 Microsoft Office 又有什么关系呢？Office 每天都被数以百万计的用户使用着，而且一直是 Microsoft 用来展示其在桌面革新和桌面生产率方面的某些最先进思想的核心产品。由此，许多人都一直期待（希望、祝愿和祈求）Microsoft 将 Office 融入 .NET 的行列。去年，一些 Office 专家在 MSDN 完成了一项出色的工作，向我们展示了 Office 和 .NET 如何协同工作（Paul Cornell 的上一篇 OfficeTalk [英文] 专栏便是明证）。但 Office XP PIA 却代表了 Microsoft 更有意义的策略性声明。

简要历史回顾

从历史的角度看，Microsoft 经常使用循序渐进的方法将新技术引入现有产品中。您还记得最初发布 VBA 的是哪个产品吗？您可能认为所有 Office 产品会同时引入 VBA，但事实上却不是。Microsoft Excel 5.0 是第一个支持 VBA 的 Office 产品。在后来发布的 Office 产品中，Microsoft 扩大了对 VBA 的支持，直至所有的产品都支持 VBA。

为什么要使用循序渐进的方法？主要是因为集成新技术而不破坏向后兼容性，以及进行大量测试都需要很大的投入。因此，Microsoft 在 Microsoft Excel 5.0 中发布了 VBA 并承诺将支持扩展到其他产品，而不是等到所有产品都集成了 VBA（这可能会需要很多年）后才发布。在短短几年的时间里，Microsoft 就彻底实现了全部计划。这种方法鼓励开发人员和 ISV 及早采用 VBA，并最终成为实现桌面产品扩展性的标准方法。例如，Microsoft Visio® 增加了对 VBA 的支持（就在 Microsoft 收购 Visio 之前）；Autodesk 也在 AutoCAD 产品中增加了对 VBA 的支持。

这说明什么？我们看到同样的方法也适用于 Office 和 .NET。首先，MSDN 的作者讲述了将 Office 和 .NET 结合在一起的好处。现在，Microsoft 已发布了 Office XP 的正式主互操作程序集。连锁反应开始了。通过发布 PIA，Microsoft 向公众做出策略性声明并向他们提供明证，证明 Office 能够在 .NET 领域中大显身手。因此，我们可以期待未来 Office 版本的 PIA，同时也可以期待将来 Office 和 .NET 的开发中会有更振奋人心的改进。请关注本专栏，因为在接下来的几个月中，Paul Cornell 和我将开始介绍下一版 Office 中的某些革新。

好了，对将来的设想就这么多，现在让我们开始关注并走入 Office XP PIA 的殿堂。

Office XP PIAs 简介

什么是 Office XP PIA？要回答这个问题，就必须清楚一些基本的 .NET 概念。让我们快速回顾几个概念。

首先，我们需要理解术语“互操作程序集”。互操作程序集是一个专门的 .NET 程序集，它包含定义 COM 类型的元数据，使用这些类型，.NET 编译器能够解析对 COM 对象的调用。有一个重要的特点值得注意 - 由于互操作程序集并未修改原始的 COM 库（实际的二进制表示），因此它只包含 COM 类型的定义。简单地说，互操作程序集包含各种所需信息，使在公共语言运行时中运行的 .NET 托管代码能够使用各种基于 Microsoft Office COM 的对象模型 API 调用 Microsoft Office 中的非托管代码。

如何创建互操作程序集？COM 组件（例如基于 Microsoft Office COM 的对象模型 API）使用类型库公开了类型信息，但 .NET 编译器并不能识别 COM 类型库，他们只能识别 .NET 元数据。因此，要使 COM 组件在 .NET 环境中可用，关键在于存在一个提取 COM 类型库并生成等效元数据的机制。公共语言运行时执行引擎包含此功能，该功能被称为“类型库导入程序”。要使用 .NET 类型库导入程序，可以通过以下两种方法：

.NET SDK 中附带的 TLBIMP.EXE 实用程序。
使用 Add Reference（添加引用）对话框从 Visual Studio .NET 中引用 COM 组件。

无论使用哪种方法，都会生成一个扩展名为 .DLL 的新程序集。.NET 应用程序使用此程序集自动启用 Office 而不是 COM 类型库。

互操作程序集和“主互操作程序集”有什么区别？除了几个值得注意的区别之外，两者几乎完全相同。主互操作程序集是由软件供应商发布的“正式”互操作程序集。对于 Microsoft Office XP PIA，Microsoft 是基于 Office COM 的对象模型的拥有者，并且发布了正式的主互操作程序集。以下两节引自 MSDN 中一篇名为 Primary Interop Assemblies（英文）的文章，该文章详细说明了 PIA 的用途：

什么是 PIA ？

同所有其他托管程序集一样，互操作程序集是部署、版本管理和配置为一个单元的类型集合。但与其他托管程序集不同的是，互操作程序集包含已在 COM 中定义的类型的类型定义（而非实现）。这些类型定义允许托管应用程序在编译时绑定至 COM 类型，并向公共语言运行时提供有关在运行时如何封送处理类型的信息。

尽管描述给定 COM 类型的互操作程序集的数目不受限制，但只有一个互操作程序集标记为 PIA。此 PIA 包含类型（由这些类型的发布者定义）的正式定义。此 PIA 还可能包含某些使类型更容易在托管代码中使用的自定义。PIA 始终由原始 COM 类型的发布者签名。

任何不是由 COM 类型的发布者提供的互操作程序集均被认为是非正式的，应当避免使用。由于在此类程序集中定义的类型不能由 PIA 的发布者签名，因此它们与 PIA 中提供的定义不兼容。

PIA 为何重要？

PIA 之所以重要，是因为它们提供了唯一的类型标识。PIA 能够将正式的类型定义与由其他互操作程序集提供的伪定义区分开。具有单个类型标识可确保应用程序（共享 PIA 中定义的类型）之间的类型相互兼容。由于 PIA 由其发布者签名并且具有 PrimaryInteropAssembly 属性，因此它可以区别于定义相同类型的其他互操作程序集。

PIA 和互操作程序集的另一区别是，COM 库的所有者可以通过在程序集中重命名或隐藏某些元素来自定义 PIA，还可以通过添加属性来更改 .NET 和 COM 之间的封送处理行为。这是使用 Microsoft Office XP PIA 而不使用您自己通过 TLBIMP.EXE 或 Visual Studio .NET 生成的互操作程序集的重要原因。虽然到目前为止所描述的工具在典型方案中运行良好，但期望它们理解深刻而广泛的 Office 对象模型的无数细微差别也是不现实的。于是，Microsoft 自定义了 PIA 以提高互操作性。

总之，说了这么多，目的是让您相信：

您需要在 Office 和 .NET 开发中使用互操作程序集。
您应该使用 Microsoft 提供的主互操作程序集，因为它们是正式版本。
正式的 PIA 具有更好的互操作性。
Microsoft 已对 Office XP PIA 进行了测试，它们很可能比你我自行生成的 PIA 更好用。

安装 Office XP PIA

下载 Office XP PIA 并将它们展开到目录中之后，您将发现有大约 43 个文件。大多数文件都使用 .DLL 扩展名。这些文件就是真正的互操作程序集。另外还有一些文件，可以帮助您将 PIA 和介绍安装过程的自述文件一起安装到 .NET 全局程序集缓存中。Office XP PIA 包含对 Microsoft Access、Microsoft Excel、Microsoft FrontPage®、Microsoft Outlook®、Microsoft PowerPoint®、Microsoft Publisher、Microsoft Visio、Microsoft Word 以及其他用于 Office 的支持库的支持。

建议您读一读 Working with the Office XP Primary Interop Assemblies（英文）这篇文章，它详细介绍了如何安装 PIA 以及各种分发选项。我不想再重复该文章中已详细介绍的内容，而是回顾几个要点。

安装 PIA 时有几个选项。首先，您可以将 PIA 安装到 .NET 全局程序集缓存 (GAC) 中。GAC 是在整个计算机范围内有效的储备库，用于储备由多个应用程序共享的程序集。GAC 位于 WINNT\Assembly 或 WINDOWS\Assembly 目录中。Microsoft Windows® Shell 扩展为我们提供了该目录的专有视图，如图 1 所示。

office10032002-fig01

图 1：全局程序集缓存

只要 GAC 中包含程序集，该程序集就可用于任何应用程序（假设安全设置允许）。另一个选项是使用被称为 XCOPY 的方法。XCOPY 方法意味着您只需将所需的 PIA 文件复制到项目目录中，设置对这些 PIA 文件的引用，然后即可继续进行。XCOPY 方法是 .NET 优于传统 COM 开发的一个体现。完成应用程序后，只需将应用程序与它们放在部署程序包中的同一个目录下即可。

您应该使用哪种方法来使用 PIA 呢？同很多事情一样，这取决于您的需要。大多数企业也许会选择将 Office XP PIA 部署到 GAC 中。这允许他们管理部署进程，并以共享方式使用程序集。这种方法可以简化应用程序的部署，因为开发人员不必将 PIA 并入他们的安装过程中。另外，由于不会部署程序集的多个副本，因此它还可以防止磁盘空间的浪费。但是我还是要提一下，即使部署了多个副本，.NET 也能确保我们不会遇到原来的组件冲突所造成的 DLL hell 问题。

在很多情况下，将 Office XP PIA 部署到 GAC 将是首选方法。但是这也不排除使用 XCOPY 方法的可能性。很多时候开发人员无法控制桌面，也不能确保 GAC 中包含所需的 PIA。另外，许多公司不希望第三方应用程序对用户的计算机进行全局系统更改，因此，将 Office XP PIA 安装到 GAC 中对于您的安装程序包可能不太现实。当您无法控制桌面，并且希望减小 PIA 不在目标计算机上的风险时，可以将您的解决方案所需的单个 PIA 文件添加到应用程序中。能够如此灵活地部署 PIA 真是让人振奋。

添加引用

在 Visual Studio .NET 中，如果我们要在应用程序中使用引用，就需要将它添加到程序集中。要将引用添加到某个 Office COM 对象，我们可以在 Visual Studio.NET 中选择 Project（项目）菜单，然后单击 Add Reference（添加引用）。或者，在 Solution Explorer（解决方案资源管理器）窗口中，在应用程序的 References（引用）节点上单击鼠标右键，也可以访问 Add Reference（添加引用）对话框，如图 2 所示。

office10032002-fig02

图 2：将引用添加到解决方案中

选择 Add Reference（添加引用），将显示 Add Reference（添加引用）对话框，如图 3 所示。

office10032002-fig03

图 3：Add Reference（添加引用）对话框

此对话框类似于我们在 Visual Basic 6.0 或 VBA IDE 中使用的Add Reference（添加引用）对话框，它允许您设置一个对外部库的引用以便在项目中使用该库。Visual Studio .NET 中的主要差别在于您不仅可以设置对 COM 库的引用，还可以设置对 .NET 程序集的引用。

当我第一次使用此对话框（如图 3 所示）时，我自认为知道它的用途，但我尝试了好几次后才真正明白。当您在 .NET 选项卡中选择库时，您将设置对 .NET 程序集的引用。我曾假设将 Office XP PIA 安装到 GAC 以后，它们就会出现在 .NET 选项卡中，可事实并非如此！要引用 COM 对象，您需要使用 COM 选项卡。在图 3 中，您可以看到我引用的是 Microsoft Word 10.0 Object Library（Microsoft Word 10.0 对象库）。当我单击 OK（确定）时，Visual Studio .NET 将查看 GAC，以确定我是否为 Microsoft Word 10.0 Object Library（Microsoft Word 10.0 对象库）安装了互操作程序集。如果已安装，GAC 中的互操作程序集将被引用。如果不存在互操作程序集，Visual Studio .NET 将使用前面介绍过的机制生成互操作程序集。

如果您要使用前面提到的 XCOPY 方法，请将所需的 PIA 程序集文件复制到您的项目目录中。然后使用 Add Reference（添加引用）对话框，并单击 Browse（浏览）按钮，浏览到项目目录中的 PIA 程序集文件。

您可以通过在 Visual Studio .NET 中查看引用的互操作程序集的 Path 属性来判断是设置了对 GAC 还是对本地互操作程序集副本的引用。例如，用 GAC 中的互操作程序集设置了对 Microsoft Word 10.0 Object Library（Microsoft Word 10.0 对象库）的引用之后，Path 属性设置为：

C:\WINNT\assembly\GAC\Microsoft.Office.Interop.Word\10.0.4504.0__31bf3856a
d364e35\Microsoft.Office.Interop.Word.dll

注意：在以上路径中插入换行符是为了提高可读性。

当我使用 XCOPY 方法时，路径属性则具有以下值：

<<Project Path>>\Microsoft.Office.Interop.Word.dll

示例 1：使用 Word 的拼写检查引擎

我经常收到以及在新闻组中发现的一个常见需求就是希望使用 Office 内置的拼写检查引擎。使用 Office 拼写检查引擎非常有意义。首先，如果您的用户在计算机上安装了 Office，他们就已经有了很好的拼写检查引擎。该引擎支持来自第三方的自定义词典，并且允许用户从 Office 用户界面上扩展词汇。还可通过 Office XP PIA 公开的 Office 对象模型获得 Office 拼写检查引擎。以下代码演示了从命令行检查句子拼写的 .NET 控制台应用程序：

Module SpellCheck
    Sub Main()
        Dim str As String = Trim(Replace(System.Environment.CommandLine, _
            "spellcheck", "", , , CompareMethod.Text))
        Dim aWords As Array = str.Split(Convert.ToChar(" "))
        Dim sWord As String

        Console.WriteLine(vbCrLf & Chr(34) & str & Chr(34) _
            & " 正在进行拼写检查。请稍候....." & vbCrLf)

        ' 创建新的 Microsoft Word 实例
        Dim objWord As New __
            Microsoft.Office.Interop.Word.ApplicationClass()
        Dim objSpellingSuggestions As __
            Microsoft.Office.Interop.Word.SpellingSuggestions
        Dim objSpellingSuggestion As __
            Microsoft.Office.Interop.Word.SpellingSuggestion

        ' Word 要求打开一个文档以使用拼写检查引擎。添加空白文档。
        objWord.Documents.Add()

        ' 依次通过每个单词
        For Each sWord In aWords
            ' 对单词进行拼写检查
            objSpellingSuggestions = objWord.GetSpellingSuggestions(sWord)
            If objSpellingSuggestions.Count > 0 Then
                ' 如果某个单词拼写错误，则给出建议的改正方案
                Console.WriteLine(Chr(34) & sWord & Chr(34) _
                    & " 拼写错误。建议更正为: ")
                For Each objSpellingSuggestion In objSpellingSuggestions
                    Console.WriteLine(Space(2) & _
                        objSpellingSuggestion.Name)
                Next
                Console.WriteLine()
            End If
        Next
        ' 关闭 Word
        objWord.Quit()
        Console.WriteLine("拼写检查完毕")
    End Sub
End Module

图 4 显示了操作中的命令行实用程序。显然，该实用程序是人为编写的示例，但使用控制台应用程序使我们可以简化代码并专注于我们感兴趣的事情上，也就是用 Visual Studio.NET 自动启用 Office。

office10032002-fig04

图 4：SpellCheck 命令行实用程序输出

查看该示例的代码，我们会发现以下逻辑：

访问命令行以获取要进行拼写检查的文本字符串。Microsoft .NET 能够很轻松地实现此操作，因为命令行参数可以通过 System.Environment.CommandLine 获得。
除去不想要的字符之后，该字符串转换为数组，且字符串中的每个单词成为该数组的元素。

下面创建一个 Microsoft Word 实例：

Dim objWord As New Microsoft.Office.Interop.Word.ApplicationClass()

Microsoft Word 要求将文档加载到应用程序中，以便使用拼写检查引擎。即使您不打算使用该文档进行任何操作也需要执行此操作。因此，该代码调用 Application.Document.Add 方法并将空白文档添加到 Word 中。
下一步，通过 GetSpellingSuggestions 方法遍历数组中的每个单词，然后将其传递到拼写检查引擎。如果某个单词拼写不正确，GetSpellingSuggestions 方法就返回 SpellingSuggestion 对象集合。
对于每个拼写有误的单词，命令行实用程序都向控制台输出一条附带更正建议的消息。

观察一下代码 - 如果您已熟悉 Office 对象模型，该代码的大部分对您来说都不会陌生。这意味着您在 Office 自动启用方面的经验也适用于 Office XP PIA。在许多方面，这种经验都让人联想起从 Visual Basic 自动启用 Office，因为一旦您获取对主应用程序的 Application 对象的对象引用，您就可以使用该对象模型来访问感兴趣的对象、方法、属性和事件。

您可能也注意到，创建 Microsoft Word 实例时创建的对象是 Word.ApplicationClass 类型。难道不应该是 Word.Application 吗？当我刚开始编写此代码时，我使用的正是 Word.Application。开始一切都很正常，直到我试图调用 objWord.Quit。键入 objWord.Quit 后，Visual Studio .NET 报告出现错误：

'Quit' is ambiguous across the inherited interfaces
'Microsoft.Office.Interop.Word._Application' and
'Microsoft.Office.Interop.Word.ApplicationEvents3_Event'. （“退出”在继承的接口 Microsoft.Office.Interop.Word._Application 和 Microsoft.Office.Interop.Word.ApplicationEvents3_Event 上不明确。）

什么？我不知道这是什么意思。经过一番研究之后（大约半个小时后），我才发现这两个对象成员具有相同的方法名称，因此相互冲突，只有使用 Word.ApplicationClass 才能正常执行。MSDN 的 Office 专家刚刚将此问题和其他几个您需要了解的问题一并写到一篇名为 Office XP Primary Interop Assemblies Known Issues（英文）的文章中。该文章解释说：“只有在使用名称不明确的事件或对象成员时才需要使用带 Class 后缀的对象。其他情况下，请使用不带 Class 后缀的对象。” 我真希望开始时就清楚这一点。

我遇到的另一个问题（Office XP Primary Interop Assemblies Known Issues [英文] 中有所介绍）就是安装在 GAC 中的 Office XP PIA 突然无法从 Visual Studio .NET 项目中引用。很明显，当用户或任何 Office 应用程序启动可导致重写 Office 类型库注册的 Office 设置操作时，会发生上述问题。要解决此问题，请重新运行 Office XP PIA 中附带的 register.bat 文件。

这不过是一系列怪事当中的两个问题，我希望 Office 小组能在将来的 Office PIA 版本中加以解决。

示例 2：使用 ADO.NET 数据集，第 2 部分

在八月份的 Office Talk 专栏中，我介绍了在Microsoft Office 中使用 ADO.NET 数据集的技术，该技术可在 .NET XML Web Service 中获得。该专栏中的方法是在 Visual Basic 6.0 中使用 Microsoft XML Core Service 4.0 编写的上百行代码。当无法在目标计算机上获得 .NET Framework 时，这是个很好的解决方案。

现在客户的计算机上通常都会有 .NET Framework，并且可以使用 Office XP PIA，因此我迫不及待地要将该代码转换为 Visual Basic .NET。让我感到吃惊的是，Visual Studio .NET 使我能够在创建了对 XML Web Service（与我在八月份的 Office Talk 专栏中引用的 XML Web Service 相同）的 Web 引用后，在大约 44 行代码中进行该转换。

让我们看看这段代码：

Imports Microsoft.Office.Interop
Module DataSet2Excel

    Sub Main()

        Dim ds As DataSet
        Dim dt As DataTable
        Dim ictrColumn As Integer
        Dim ictrRow As Integer

        ' 创建 Excel 实例
        Dim xl As New Excel.Application()
        xl.Workbooks.Add()
        xl.Visible = True
        xl.Range("A2").Value = "正在检索 Web 服务数据。请稍候.."

        Try
            xl.ScreenUpdating = False

            ' 将 Web 服务中的数据检索到数据集中
            Dim objOrdHist As New com.fabrikam.services.OrderHistory()
            ds = objOrdHist.OpenOrders
            dt = ds.Tables(0)

            ' 将列名称插入到 Excel 中
            For ictrColumn = 0 To dt.Columns.Count - 1
                xl.Range("A1").Offset(, ictrColumn).Value = _
                    dt.Columns(ictrColumn).ColumnName
            Next

            ' 将数据集数据插入到 Excel 中
            For ictrRow = 0 To dt.Rows.Count - 1
                xl.Range("A2").Offset(ictrRow). _
                    Resize(1, ictrColumn).Value = _
                    dt.Rows(ictrRow).ItemArray()
            Next

            ' 对 Excel 中的数据列表进行格式化
            With xl.Sheets("Sheet1").Range("A1")
                .AutoFilter()
                .AutoFormat(Excel.XlRangeAutoFormat. _
                    xlRangeAutoFormatList2)
            End With

        Catch e As Exception
                MsgBox(e.ToString, MsgBoxStyle.Critical, _
                    "Data2Excel 错误")
                xl.ActiveWorkbook.Close(False)
                xl.Quit()

        Finally
                xl.ScreenUpdating = True

        End Try

    End Sub
End Module

为方便起见，我又一次使用了 .NET 控制台应用程序。第一行代码创建了一个快捷方式引用，该引用使用 Imports 关键字从引用的项目和程序集中导入命名空间：

Imports Microsoft.Office.Interop

这使得从源代码模式中引用对象类型变得更为容易，并且使源代码也更容易阅读。例如，我首先用以下代码创建了一个 Microsoft Excel 实例：

Dim xl As New Excel.Application()

Microsoft Excel 实例将读取以下代码，而不对库引用使用 Imports 关键字：

Dim xl As New Imports Microsoft.Office.Interop.Excel.Application()

这也可以执行，但时间会很长。作为比较，我们回顾一下示例 1，该示例中未使用 Imports。进一步检查代码，会发现在该 Microsoft Excel 实例中添加了一个新工作薄。在禁用屏幕更新（以防屏幕在工作薄中插入数据时闪烁）之前，出现一个提示用户等待的消息：

xl.Range("A2").Value = "正在检索 Web 服务数据。请稍候.."

当 XML Web Service 中的数据插入到工作薄中时，该临时消息将被覆盖。图 5 显示了代码此时的输出状态。

office10032002-fig05

图 5：Microsoft Excel 在检索数据时提示用户等待

然后，示例代码用 XML Web Service 中的可用数据结果填充 DataSet 对象。请注意，不存在将 XML Web Service 数据转换为数据集的 XML 分析代码。Microsoft .NET 通过 XML Web Service 对远程数据集提供支持，并且能够将数据集序列化为 XML 并进行反序列化。然后使用熟悉的 Microsoft Excel Range 对象，代码通过遍历数据集中包含的数据表插入列标题和相关数据。最后对工作薄进行格式化，以获得更好的外观，如图 6 所示。

office10032002-fig06

图 6：使用 XML Web Service 提供的 ADO.NET DataSet 中的数据填充的工作薄

小结

Microsoft Office 和 .NET Framework 的组合具有许多激动人心的潜在功能。在我所期待的未来几年内 Office 和 .NET 之间的有益关系中，Office XP PIA 迈出了第一步。请花些时间使用一下 Office XP PIA，并阅读本文引用的其他文章。

Share via