17

We have developed a product that is a standard VSTO addin (Word 2010 and Word 2013, x86 only). By default when it is installed, it is installed for all users (ie. the addin registry entries are inserted into HKLM - HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node]\Microsoft\Office\Word\Addins).

When the value for the LoadBehavior reg key is set to 0x3 (i.e. "Load at Startup"), the addin works perfectly fine, however when we set the value for LoadBehavior to 0x10 (i.e. "Load on demand"), the addin does not work as we would expect:

Due to UAC (and that Word does not run elevated), the value of LoadBehavior in HKLM is not changed from 0x10 to 0x9 but instead is overridden by creating a LoadBehavior key (with value 0x9) in the HKCU hive.

Unfortunately, we have found that this HKCU overridden value is not taken into account unless the Manifest key is present in the HKCU hive along with LoadBehavior). More info on this related thread: https://social.msdn.microsoft.com/Forums/vstudio/en-US/3776734b-333e-423b-9c08-7c7a441c3e94/load-behavior-and-word-addin?forum=vsto

The 'obvious' remedy for this issue is to write the Manifest into HKCU for each user (as well as in HKLM) at install time OR when each user run the addin the first time. There are however some serious drawbacks with this approach:

  • Uninstalling the addin requires removing every user HKCU values to prevent users experiencing loading issues (this is not recommended and poses other issues/complications such as the need to use Active Setup - Remove registry keys under HKCU on a per machine installation).
  • Users which have these values in their (roaming) HKCU hive, experience issues when they login to a machine in the same domain which does not have our addin installed.

Is it a bug that the manifest is not obtained from HKLM where the LoadBehavior is set appropriately in HKCU? I think this issue would be resolved if the LoadBehavior in HKLM could be overridden in HKCU without the need for the Manifest value to be overridden as well.

Anyone knows of a way to overcome this issue?

4

2 回答 2

1

没有将 UAC 设置为“从不通知”，我不知道有什么方法可以直接解决您的问题。但是，我将建议一种解决方法，使您基本上可以按需加载。

我建议您将 VSTO 插件更改LoadBehavior为0x0（未加载 - 不自动加载），然后在自动加载的模板中使用 VBA 命令来控制加载项的加载时间。以下是要采取的步骤的概要：

  1. 在 Visual Studio 中，确保插件中的功能区被编码为 XML 文件（不是使用 Visual Designer 创建的）。在此功能区中定义自定义命名空间。
  2. 创建 Word 模板 ( .dotm)。使用Microsoft Office 的自定义 UI 编辑器在此模板中嵌入功能区选项卡的 XML，该功能区选项卡的标签和位置与加载项中的选项卡相同。将 XML 中的命名空间定义为与 Visual Studio XML 代码中的命名空间相同，以便它们共享相同的命名空间。此外，定义一个将加载您的插件的按钮（并且可能还可以在您的插件中执行其他功能）。

  3. 在您的模板中编写一个子程序以使用以下代码加载您已卸载的0x0插件：

    Application.COMAddIns(ProgID).Connect = True

    ProgID是您的 ProgID 的项目 ID，或者是引号中的 ProgID 的实际名称。

  4. 在您的模板中编写一个回调，该回调将调用代码以从按钮加载插件。

  5. 将模板放在 Word 的 STARTUP 目录中。对于 Word 2010，即C:\Program Files (x86)\Microsoft Office\Office14\STARTUP

我们想要发生的是，当 Word 启动时，VSTO 插件已安装但未加载。您创建的模板会自动从 STARTUP 目录加载，并将您的应用程序的功能区选项卡放置在 Word 中。由于未加载 VSTO 插件，因此这些控件当前不可见。但是，在执行上述步骤后，当单击模板 XML 中的按钮时，您的插件会将其控件加载到同一功能区，因为它们共享一个命名空间。当 Word 关闭并重新启动时，它会重置为正在安装但未加载的 VSTO 插件。

更进一步，如果您想避免额外单击加载 VSTO 插件控件，您可以想象在模板中重新创建 VSTO 插件的 XML，并让每个控件调用代码来加载您的 VSTO 插件，隐藏模板的功能区控件，并执行您的插件的功能。通过这种方式，您将拥有由模板的 XML 提供的占位符功能区，以及真正的插件加载和按需执行操作。

于 2015-12-21T23:34:14.853 回答
0

您使用Load On Demand的原因很可能是为了提高启动性能，如MSDN中所述。然而，按需加载带来了一系列问题（不支持动态功能区 UI 状态、HKLM 部署问题等）。

正如您已经说过的， Load at Startup没有问题。因此，加载加载项的推荐方法是使用LoadBehavior.0x3

如果您遇到加载项加载性能问题，一种解决方案可能是使用轻量级加载项，该加载项始终在启动时加载，然后此加载项充当实际加载项的加载程序。

于 2015-12-03T10:02:59.033 回答