在这篇文章里面，我将向大家介绍如何在.Net中访问Office所公开的编程接口。其实，不管是使用哪种具体的技术来针对Office进行开发（比如VSTO，或者用C#编写一个Office Add-in，或者在一个WinForms程序中调用Office的功能，甚至在一个ASP.NET应用的服务器端启动一个Excel进程），只要是基于.Net平台，这篇文章所描述的内容都是有价值的。
在这篇文章以及后续的文章中，所有的演示都将基于Office 2003 Professional和Visual Studio 2005。使用Visual Studio 2005并不代表我们不能在Visual Studio 2003中使用这些方法来访问Office编程接口，相反，这篇文章以及后续文章中的几乎所有演示，都能在Visual Studio 2003中完成。笔者使用Visual Studio 2005的原因只是因为喜欢它更好的IDE特性。:)
一、Office PIA
在第一篇文章中曾经说过，Office的编程接口都是通过COM组件公开的，任何访问Office编程接口的程序，实际上都必须要最终调用Office COM组件。如果你是一个刚从事Windows平台开发不太久，一开始就是学习和使用.Net的程序员，也许你又要感到郁闷了。所幸的是，.Net能够让开发人员非常方便的访问COM组件。我会用尽量简洁明了的描述，让大家理解我们在.Net中是如何访问Office COM组件的。
（一）Interop Assembly
在.Net Framework中，提供了一项叫做COM Interop的技术，这项技术就是专门用于让我们能够在.Net代码中直接访问COM组件的。它的基本原理是，.Net Framework能够自动针对某一个COM组件，帮助开发人员生成一个Interop Assembly（互调用程序集，后面简称IA），IA是一个完全的托管程序集。IA中的名称空间、类、方法等等，都是针对那个COM组件对应的。在我们的.Net程序中，我们可以直接引用这个IA，并且调用里面相关的方法，这时IA就会帮我们再去访问真正的COM组件里面的相应方法。最后的效果就是，在我们自己的应用程序中，只需要调用一个纯粹.Net的IA即可。
下面的图片说明了IA是如何帮我们的程序访问到COM组件的。
生成一个IA的方法非常简单，当我们在Visual Studio开发环境中添加一个新的COM组件引用时，Visual Studio就会自动帮我们生成一个相应的IA。如下图，我们示范在一个项目中引用Microsoft XML 5.0组件。
当在上图中点击OK按钮，Visual Studio就已经自动为我们生成了一个针对Microsoft XML 5.0组件的IA。打开项目目录的obj\debug目录，就能够看到一个名称为Interop.MSXML2.dll的程序集文件，这个文件就是自动生成的IA，并且在项目中，Visual Studio也自动引用了这个IA程序集。如下图。
（二）Primary Interop Assembly
我们在自己的应用程序中，访问Office COM组件的方法的基本原理，就如同下面所述，都是通过COM Interop，透过IA间接的访问到Office中的COM组件。但是针对Office这个软件，则有一点点特殊的区别，那就是我们不应该自己在Visual Studio中生成一个“自己的”访问Office COM的IA，而需要使用微软提供的“官方的”PIA。
PIA的意思可以理解为“官方互操作程序集”，它和IA最主要的区别如下：
1、IA是由开发人员在开发机器上通过向导自动生成的，PIA是由软件厂商（针对Office这个软件而言，就是指微软）提供的；
2、PIA经过了厂商的优化处理，使之更容易被.Net调用；
（三）Office Primary Interop Assembly
所以，我们都应该使用PIA来访问Office COM组件，而不应该使用IA。那么如何把Office PIA安装到我们的电脑上呢？
如果我们的机器上已经安装了.Net Framework，那么在安装Office时，在安装向导的高级自定义选项中，我们在每个组件（Word、Excel、PowperPoint等）的子选项中，都能看到一个“.NET可编程性支持”，选择安装它，Office2003的安装程序就会自动把PIA安装到我们的计算机上。
另外，对于Office PIA的客户端分发（就是说，给我们软件的用户都统一装上PIA），微软专门提供了一个安装包。可以在http://www.microsoft.com/downloads/details.aspx?FamilyID=3c9a983a-ac14-4125-8ba0-d36d67e0f4ad&DisplayLang=en下载到这个分发安装包。
Office PIA按照Office的各个组件（Word、Excel、PowerPoint、Outlook等），分成多个单独的程序集。比如Word对应的PIA程序集是Microsoft.Office.Interop.Word.dll（程序集里面的类都放在命名空间Microsoft.Office.Interop.Word中），Excel对应的程序集是Microsoft.Office.Interop.Excel.dll（程序集里面的类都放在命名空间Microsoft.Office.Interop.Excel中）。另外，Office公用的一些组件（比如菜单栏）放在一个单独的程序集中：Office.dll（对应的命名空间是Microsoft.Office.Interop.Core）。
如果我们的开发机器上已经安装好了Office PIA，那么当我们通过上面所述的方法，在Visual Studio中引用Office COM组件时，Visual Studio会检测到本机已经安装了Office PIA，然后，它会直接引用安装好了的PIA，而不会再自动生成一个新的IA。
如下图，我们在Visual Studio中添加一个对Word COM组件的引用（Word在COM组件列表中是“Microsoft Word 11.0 Object Library”，相似的，Excel、Outlook、PowerPoint的COM组件名称都遵循这个规律）。
在上图中点击OK按钮后，在项目管理器中就可以看到，Visual Studio已经帮我们引用了需要引用的组件。实际上，除了我们选择要引用的Word组件外，其他额外但是必需的诸如Microsoft.Office.Core、stdole、VBIDE等组件也已经被自动引用进来了。
在上图的Word组件引用上点击鼠标右键，查看它的属性，在它的路径属性中，我们可以看到这个PIA文件其实是在“C:\Windows\assembly\...”目录中，这个目录也就是我们机器上的全局程序集缓存（GAC，Global Assembly Cache）所在的目录。这是因为Office PIA是被安装到机器上的GAC中，所以对Office PIA的引用会直接指向GAC中的相应文件。
二、深入浏览Office PIA
如果读者曾经使用过VBA进行过开发（或者使用其他的开发工具诸如VB/VC/Delphi直接调用过Office），那么其实你已经对Office COM接口有了一定的了解，因为在VBA编辑器中所编写的操作诸如Application、Document、Range的代码，其实正是在操作Office COM组件中的Application、Document、Range这些类。
我们已经知道，在Office PIA中，已经把Office COM组件进行了封装，所以我们可以预见，对于每一个Office COM组件中的类或者接口，在Office PIA的程序集中，我们应该都能找到一个对应的类或者接口。接下来，我们就用对象浏览器直接打开Office COM组件，然后再打开Office PIA，这样我们就可以对照它们，更清楚的理解它们。
asp.net｜使用.Net访问Office编程接口(PIA和IA的区别)
