Office主互操作程序集（PIA）
在了解如何构建Office解决方案之前，您需要更详细地了解在.NET中与Office对象模型通信的托管程序集。用于与Office通话的托管程序集称为Office主互操作程序集（PIA）。
如前所述，当您正在与.NET中的Office对象模型交谈时，您可以通过称为COM互操作的.NET技术与之交谈。 Office对象模型全部以公开COM接口的非托管代码（C和C ++）编写。要通过托管代码（C＃或Visual Basic）与这些COM接口通话，您可以通过一个包装器进行通话，允许托管代码与Office的非托管COM接口进行交互操作。这个包装器是一组被编译成一个称为主互操作程序集或PIA的程序集的.NET类。
描述这些程序集时使用“primary”一词，因为它们是经Office认可的用于与Office对象模型通信的包装器。需要这个指定，因为您可以使用.NET提供的工具（称为TLBIMP）为Office COM对象模型创建自己的包装器。您自己创建的包装器称为互操作程序集（IA），而不是主互操作程序集。即使您可能会尝试使用TLBIMP并构建自己的互操作程序集，但除了Office提供的互操作程序集之外，您也不应该使用任何其他操作来进行Office开发。如果每个开发人员都为自己的Office开发人员创建了自己的套装，那么没有Office解决方案可以与任何人的解决方案进行互操作;每个interop包装类，例如每个开发人员创建的Worksheet将被视为一种不同的类型。即使我创建的Interop程序集有一个Worksheet对象，并且您创建的Interop程序集具有一个Worksheet对象，我无法传递我的Worksheet对象，也不能传递给您的Worksheet对象。我们需要使用相同的互操作程序集：主互操作程序集。
不建立自己的互操作程序集的第二个原因是Office已经对PIA进行了特殊修复，以便在执行Office开发时使它们更好地工作。如果您生成自己的，那么您很可能遇到在PIA中修复的问题。
安装PIA
Office 2003 PIA可通过Office 2003安装程序获得。 Office 2003 PIA也可以作为Microsoft Windows Installer包提供，您可以使用应用程序重新分发。要通过Office 2003安装程序安装Office 2003 PIA，进行安装时，请在Office 2003安装向导的第一步中选中“选择应用程序高级自定义”复选框。然后在向导的下一个屏幕中显示的树控件中，您将在每个应用程序下面看到一个可编程控制器可用的.NET可编程性支持节点，如图1-4所示。单击每个这些.NET可编程支持节点，并确保您从我的计算机设置运行。此外，在树中的Office工具节点下，您可能需要启用Microsoft Forms 2.0 .NET可编程支持和智能标记.NET可编程性支持。获取Office 2003 PIA的第二种方法是完成Office 2003all的安装，.NET可编程性支持将自动打开。
Office PIA安装到全局程序集缓存（GAC）。 GAC通常位于Windows目录的Assembly子目录中。
有多个Office PIA可用。 表1-4列出了最常见的一些。 这里列出的一个PIA是Office.dll PIA，它是在Office应用程序（如CommandBar）之间共享的常见类型。
参考PIAs
添加对PIA的引用对于大多数VSTO项目是不必要的，因为引用将自动为您添加。 本书中的控制台应用程序示例，例如自动化Excel的控制台应用程序示例可以键入Visual Studio控制台项目并编译，但必须先添加对必要的PIA的引用。 要添加引用，请在Visual Studio解决方案资源管理器中右键单击项目下的“引用”文件夹，如图1-5所示。 在右键单击“引用”文件夹时，从弹出的菜单中选择“添加引用”。
选择出现的“添加引用”对话框的COM选项卡，如图1-6所示。 COM引用按组件名称列出，与表1-4中的描述列匹配。 因此，要添加对Excel PIA的引用，请选择Microsoft Excel 11.0对象库，然后单击确定按钮将Excel 2003 PIA参考添加到项目中，如图1-6所示。
请注意图1-6中“添加引用”对话框的“COM”选项卡中的“路径”列显示PIA包装的COM库的路径。例如，Microsoft Excel 11.0 Object Library指向您的计算机上Excel.EXE可执行文件的位置。当您选择这些引用并关闭对话框时，可以通过扩展项目中的“引用”文件夹，右键单击添加的引用，然后选择“属性”，来检查添加的实际引用的属性。您将看到Visual Studio计算出GAC中与您选择的COM对象相对应的PIA托管对象。在这种情况下，您将不会获得对Excel.EXE可执行文件的引用，而是GAC中的Microsoft.Office.Interop.Excel.dll。
最后，请注意，即使您没有明确添加对Microsoft Office 11.0 Object Library（office.dll）的引用，也为您添加了一个引用。这是因为Excel 11.0 Object Library使用Microsoft Office 11.0 Object Library中的类型。 Visual Studio检测到这一点，并自动将所需的Office PIA添加到您的项目引用。
浏览PIA
当您看到在Visual Studio中的对象浏览器中引用的PIA时，您可能会发现自己很困惑。对象浏览器显示了作为互操作包装器一部分创建的许多辅助对象。例如，考虑.NET Interop对于看似简单的Excel Application对象的引用。它变成一个多关联的头部引用（8个头标准引用，36私自引用）。以下所有以下是在浏览器中与Excel Application对象相关的公共类型：
Interfaces（接口）
-
_Application
-
AppEvents
-
AppEvents_Event
-
Application
-
IAppEvents
Delegates（委托）
-
AppEvents_*EventHandler (29 of them)
Classes（类）
-
AppEvents_SinkHelper (AppEvents)
-
ApplicationClass (_Application, Application, AppEvents_Event)
此图形针对Chart，OLEObject，QueryTable，Worksheet和Workbook。
我们尝试通过从Excel Application对象的原始COM定义向后工作来解开这个混乱。 Application对象的COM coclass看起来像thisit有两个接口，一个称为_Application的主接口和一个名为AppEvents的事件接口。 您可以将coclass视为定义COM类实现的接口的东西。
coclass Application { [default] interface _Application; [default, source] dispinterface AppEvents; };
TLBIMP（用于处理Excel的COM类型库并使用PIA）直接导入_Application和AppEvents接口，因此这解释了八种类型中的两种来自哪里。但是AppEvents界面不是很有用，似乎像某种TLBIMP转换的工件。它必须进一步处理，以创建后面描述的AppEvents_Event的另一个界面。
当TLBIMP处理COM coclass时，它将创建一个名为ApplicationClass的.NET类，它通过获取coclass名称并附加Class命名。它还创建一个与名为Application的coclass同名的.NET接口。如果您在浏览器中查看应用程序，它没有属于自己的属性和方法，但它来自与coclass相关联的其他两个接口：_Application和AppEvents_Event。
我们还没有解释AppEvents_Event接口来自哪里。当TLBIMP处理coclass上的AppEvents事件接口时，它会创建几个帮助类型。首先，它创建AppEvents_Event，它看起来像AppEvents，但事件和委托类型替换AppEvents中的方法。它还创建名为AppEvents_ * EventHandler的代理，其中*是原始AppEvents界面上每个方法的方法名称。最后，它创建一个可以忽略的AppEvents_SinkHelper。
这只会使IAppEvents界面无法解释。 TLBIMP直接导入此接口，因为它是Excel类型库中的公共类型。你也可以忽略这个。这实际上是AppEvents的重复，除了AppEvents在类型库中声明为dispinterface，而IAppEvents被声明为双重接口类型。
那么你真的使用哪些？基本上，你应该只在代码中使用Application接口（派生自_Application和AppEvents_Events）和代理。你通常可以假装别人不存在。此规则的一个例外是当方法和事件名称相冲突，如本章前面所述。要在要连接到事件时要调用该方法或AppEvents_Event接口的方法和事件之间消除歧义，则必须将其转换为_Application接口。表1-5给出了一个总结。
由TLBIMP为coclass创建的应用程序接口以有趣的方式表现。 您可以在C＃中编写代码，使其看起来像您正在创建应用程序界面的一个实例，我们都知道这是不可能的：
Excel.Application myApp = new Excel.Application();
真的，这是在幕后使用ApplicationClass的语法糖（应用程序界面归因于将其与ApplicationClass相关联）来创建一个Excel Application对象并返回相应的接口。
最后，我们前面提到这个模式对于Chart，OLEObject，QueryTable，Worksheet和Workbook都是重复的。 图表映射是带ChartEvents的图表和AppEvent的直接应用程序，您将得到一般的想法。 工作表有点不同 它的coclass看起来像这样：
coclass Worksheet { [default] interface _Worksheet; [default, source] dispinterface DocEvents; };
所以对于工作表，使用Worksheet替换Application，而是将AppEvents替换为DocEventsyielding DocEvents_ * EventHandler作为WorkSheet事件的代理。
QueryTable甚至是极限。 它的coclass看起来像这样：
coclass QueryTable { [default] dispinterface _QueryTable; [default, source] dispinterface RefreshEvents; };
所以对于QueryTable，使用QueryTable替换Application，并将AppEvents替换为Refresh Event，从而生成RefreshMents * EventHandler作为QueryTable事件的委托。
Dummy方法
当您在Visual Studio中的对象浏览器中查看Excel PIA时，您可能会注意到其中包含文本Dummy的大量方法。甚至有一个名为IDummy的界面。
不，这不是Excel的侮辱你的智慧的方式。一切都是虚拟的，它是一种测试方法，在Microsoft的内部“调试”版本中实际上具有合法目的和更具描述性的名称。例如，Application.Dummy6在Excel的调试版本中称为Application.DebugMemory。在Excel的零售版本中，每种方法都重命名为Dummy。这些Dummy方法中的所有508实际上都在调试Excel中做了一些事情，但是在零售版本的Excel中，除了在调用时引发错误，它们什么都不做。
Excel将这些标记为“隐藏”，但C＃对象浏览器默认显示隐藏方法。当您在C＃对象浏览器中查看PIA时，您将看到这些Dummy方法。如果创建Visual Basic项目，Visual Basic对象浏览器将隐藏具有此属性的方法和属性。
结论
本章介绍了Office对象模型，并研究了对象模型的基本结构。 您学习了如何使用对象，集合和枚举在任何对象模型中找到的基本类型。 您还学习了如何使用Office对象模型中的对象和集合公开的属性，方法和事件。
本章介绍了将Office对象模型暴露给.NET代码的Office主互操作程序集。 您学习了如何在Visual Studio项目中使用和引用Office PIA。 本章还介绍了在对象浏览器中查看PIA时可以忽略的内容。
下一章将开始研究Office编程中使用的基本开发模式，并提供各种示例。