根据我自己的经验:
如果您想以 Office 2003 及更高版本为目标,那么您将使用 Office 2003 PIA - 并将自己限制为 Office 2003 API。该代码将在 Office 2003或更高版本上运行。您仍然可以使用反射调用 Office 2007 函数,但这并不令人愉快。
我想如果您的基准版本是 Office 2000,情况大致相同——尽管我没有尝试过,而且我相信 Microsoft 自己提供 PIA 的最早版本是 Office 2002 (XP)。
您可以为 2000 创建自己的 Interop 程序集,我没有理由相信您不能在 95 年这样做,尽管您是我见过的第一个要求 95 支持的人!不用说,如果您创建自己的 Interop 程序集,则需要将它们与您的应用程序一起部署。
在任何情况下,您都希望使用可以使用的最高Office 版本作为基准,这样您就可以支持尽可能多的功能,而无需借助反射。您应该在仅安装了该版本 Office的机器上开发代码。
在我的情况下,我为 Office 2003 开发并且知道我的用户也有 2003。所以,我要求他们确保他们启用了“.NET 可编程性支持”功能(您可以通过添加/删除通过 Office 2003 设置来完成程序,如果您选择更改选项)。该选项基本上将 PIA 安装到 GAC。对于那些无法做到这一点的用户,我的安装程序会检测到缺少 PIA 并在安装我的应用程序之前安装它们(就像 .NET 框架一样)。
XCOPY 部署?是的,我也想要那个——但算了吧。一方面,如果您的加载项将在“高”安全模式下工作,那么您将需要一个代码签名的 COM“垫片”来位于您的代码和 Office 之间,并且需要注册。我相信 VSTO 提供了自己的 shim,如果您选择走这条路(我没有,因为我需要能够从头开始“驱动”Office,而不是依赖用户来启动应用程序)。
部署 - 以及处理安装和安全问题 - 是使用 .NET 进行 Office 插件开发中最困难的部分之一,当您认为自己已经完成时,它会在最后出现,这是一个真正的挑战。
我的强烈建议是省去几天和几周的麻烦,看看Add-in Express。我自己最近才遇到这个问题,从那以后一直在踢自己,因为它可以为我节省很多时间。它有几个我认为对你有用的好处:
- 它允许您创建针对 Office 2000 到 Office 2007(抱歉,不是 '95)的单个加载项,无论您的开发 PC 上碰巧有什么版本。
- 它为您创建了一个安装程序(甚至可以在 Vista 上运行!),这本身就是物有所值的。
- 它带有自己的 COM shim,并且集成到您无需担心的程度。
- 它将允许您拥有一个加载项,该加载项在 2003 及之前的 Office 版本中具有菜单/工具栏界面,但在 2007 中具有功能区界面。
请注意,我与 Add-in Express 没有任何关系(除了作为最近的客户),但同样我还没有将我的项目转换为使用它。我所做的初步测试让我相信它非常好——而且绝对是中小型项目的必经之路。