Word 2003 add-in limitations

Question

Are there known limitation to the numbers or size of add-ins in Word?

At the moment, if I do Application.COMAddIns.Count in a copy of Word, I get 4, one of which I wrote and the other three are

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

which are iManage (FileSite 8.2, actually) and WorkShare. On top of that, there are eight templates in the various startup directories, each with their own VBA project, so there's an awful lot of custom code being loaded into Word.

Obviously, when a running copy of Word with no documents open uses 115MB of RAM, it takes a long time to open the application.

We seem to mostly be getting slowdowns rather than out-and-out crashes, but I'm concerned that if we add much more then we will start getting lots of crashes. Are other people aware of these sorts of issues with Word getting too many plug-ins?

Answer 1

I'm more in the Excel camp with lots of add-ins loaded, but it's a comparable scenario. There are some slow-downs with Excel as they consume more and more memory but I've never seen it crash due to the sheer number of them or fail to load one because it says I already have too many.

This would be more of a system memory issue rather than how many total add-ins Word can handle. The more you load into memory the more you're going to slow down. Plus, with Office 2003's add-in crash protection Word will disable an add-in if it is determined that that add-in was why Word crashed. I've seen that happen many times when starting Excel with them all loaded. Usually this is because of our own in-house developed add-ins that admittedly don't have the world's greatest error trapping in them...

As you obtain additional add-ins you should be testing them on a base-level machine prior to rolling it out into your production environment. With that you can get a gauge on what kind of system resources the add-in consumes and how it plays with the other add-ins you're loading. Commercial manufacturers should also be providing you with system requirements to help you plan for the installations, including memory requirements.

If you find that your custom add-ins are creating some of the problem then you really need to review your code for possible optimizations.

Answer 2

I think the slow down is likely due to the additional overhead of loading into memory the Office Primary Interop Assemblies (PIAs) and, in particular, the Visual Studio Tools for Office (VSTO) runtime. It depends whether the add-in developers used VSTO or COM only. It could also depend on any other dependencies (DLLs) the add-ins may need to load on start up and/or data that have to be saved on shut down.

To help you determine if additional add-ins will further affect the user experience I suggest you:

1. Measure start up and shut down times of your existing configuration. Do this once when the system is started and again when Word has been closed and reopened during the same session. Did the two start up times differ significantly? What about the shut down times?

2. Disable all add-ins. Repeat the tests in 1. Did a configuration without add-ins increase performance?

3. Re-enable each add-in, one at time, repeating the tests in 1. each time. Were startup/shutdown times affected the same for each add-in or did some affect times more than others?

The above sequence of tests may seem laborious but it should take less than an hour and you should have enough information to answer your question at the end of it. You may also see differences depending on what other Office apps are already open when you start Word.