Word 2003加载项限制

Word中加载项的数量或大小是否有已知的限制?

目前,如果我在Word的副本中执行Application.COMAddIns.Count,则会得到4,其中一个是我写的,另外三个是

WordOptimisingAddin iManage Word2000 integration (Ver 1.3) Workshare Add-In For Microsoft Word 

这是iManage(FileSite 8.2,实际上)和WorkShare。 最重要的是,在各个启动目录中有八个模板,每个模板都有自己的VBA项目,所以有很多自定义代码被加载到Word中。

很显然,当没有打开文档的Word的运行副本使用115MB的RAM时,打开应用程序需要很长时间。

我们似乎主要是减速,而不是彻底崩溃,但我担心,如果我们添加更多,那么我们将开始得到大量的崩溃。 其他人是否意识到这些与Word获得太多插件的问题?

我更多的在Excel阵营中加载了大量的加载项,但这是一个可比的场景。 Excel有一些缓慢的消耗,因为它们消耗越来越多的内存,但是我从来没有看到它由于它们的数量太多而崩溃,或者没有载入一个,因为它说我已经有太多了。

这将是更多的系统内存问题,而不是Word可以处理多less个加载项。 你加载到内存越多,你会放慢。 此外,如果确定该加载项是Word为什么崩溃,则使用Office 2003的加载项防护function,Word将禁用加载项。 我已经看到,这些事情发生了很多次,当他们全部加载启动Excel。 通常这是因为我们自己的内部开发插件,确实没有世界上最大的错误陷阱…

当你获得额外的插件时,你应该在基础级别的机器上testing它们,然后把它们推出到生产环境中。 通过这个function,您可以了解外接程序消耗的系统资源以及与您正在加载的其他加载项的关系。 商业制造商也应该为您提供系统要求,以帮助您规划安装,包括内存要求。

如果您发现您的自定义加载项正在创build一些问题,那么您确实需要查看可能的优化代码。

我认为减慢速度可能是由于将Office主互操作程序集(PIA),特别是Visual Studio Tools for Office(VSTO)运行时加载到内存中的额外开销。 这取决于加载项开发人员是否仅使用VSTO或COM。 它也可能依赖于加载项可能需要加载的任何其他依赖关系(DLL)和/或在closures时必须保存的数据。

为了帮助您确定额外的加载项是否会进一步影响用户体验,我build议您:

  1. 测量您现有configuration的启动和closures时间。 在系统启动时再次执行此操作,并在同一会话中closures并重新打开Word时再执行此操作。 这两个启动时间是否有显着差异? 那closures时间呢?

  2. 禁用所有加载项。 在1中重复testing。没有加载项的configuration是否会提高性能?

  3. 每次重新启用每个加载项,每次重复1.中的testing。 每个加载项的启动/closures时间是否都受到相同的影响,或者影响时间比其他更多?

上述testing顺序可能看起来很费力,但应该不到一个小时,你应该有足够的信息来回答你的问题。 您也可能会看到差异取决于其他Office应用程序已启动Word时已打开。