谁动了我的插件？
之前提到了 VSTO 2005 SE (以下简称 Cypress) 开发的 Office 插件可能无法被装载，微软已经提供了修正此问题的更新程序。现在我们来探究一下引发此问题的根本原因——谁动了我的插件？
先了解一下 Cypress 针对 Office 2003 插件的基本装载原理。用 Cypress 开发的 Office 插件并不是直接被 Office 应用程序加载的，编译得到的 .NET 程序集没有被注册为 COM 组件，而是由一个 Cypress 提供的“Loader”加载。向 Office 应用程序注册插件信息的时候，COM 注册信息中“InprocServer32”实际上指向 Cypress Add-in Loader，并且提供一个清单文件（Manifest）告诉 Loader 真正应该加载的 .NET 程序集信息。这样做的好处有很多：各个 VSTO 开发的插件不会互相干扰（Loader 会为它们创建各自的应用程序域）；Loader 还可以帮助检查插件的新版本、提供插件自动升级功能；还可以对插件程序集的安全权限进行控制等等。
至于 COM 注册信息，我们知道在 Windows 中有三个地方可以存放（不考虑 Wow64 的情况）：
HKEY_CURRENT_USER\Software\Classes
HKEY_LOCAL_MACHINE\Software\Classes
HKEY_CLASS_ROOT （上面两个的合并版本）
在 Cypress 的 RTM 版本中，插件的 COM 注册信息被写入 HKEY_CURRENT_USER\Software\Classes。因为这样做可以保证开发人员不需要管理员权限就可以调试、部署。这种方法在 Windows 2000 / XP / 2003 的平台上没有任何问题。而在 Windows Vista 中，新的安全特性“Mandatory Integrity Control ”使包括 Office 2003 在内的 COM 应用程序行为发生了变化。如果应用程序是以“中等”或者更低的 Integrity Level 运行，COM 信息会从 HKEY_CLASS_ROOT 读取，包含了 Cypress 写入 HKEY_CURRENT_USER\Software\Classes 中的信息；但是如果应用程序以高于“中等”的 Integrity Level 运行（即“以管理员身份运行”），或者 UAC 关闭，COM 信息只从 HKEY_LOCAL_MACHINE 中读取。在这种情况下，Office 2003 无法找到 Cypress 插件写入的信息，所以就导致插件装载失败！
如果开发者在 Windows Vista 中“以管理员身份”启动 Visual Studio 2005，就会因为上述的原因无法在 IDE 中调试插件。因为此时的 Visual Studio 2005 进入调试模式启动的 Office 2003 程序默认也是“以管理员身份”运行的。
为了修正这个问题，Cypress 的修正程序将改变插件信息的写入行为：先尝试写入 HKLM，如果因为没有权限而失败，再写入 HKCU。这样，即便 Visual Studio 和 Office 2003 被提升为“管理员身份”运行，也能够保证插件的 COM 信息被找到。
值得开发人员注意的是，这次发布的 Cypress 修正程序并没有对插件工程配套的安装程序工程作任何修改（见图）。我们必须要自己在 HKLM 中添加和 HKCU 中同样的信息，才能保证插件安装在 Windows Vista 的机器上也可以完全正常工作。
最后顺带提一下，Office 2007 “天生”就认识 VSTO 开发的插件，所以就没有 Office 2003 那样的麻烦事儿了。
posted on 2007-08-30 00:26:00 by vsto 评论(1) 阅读(4831)
