Office Shared Add-ins: Issues - Part 1
November 29, 2010 by
If you ever had the opportunity (more like misfortune) to create
add-ins for Microsoft Office, chances are good that you might have found deployment
to be rather cumbersome at times.
You're faced with all kinds of issues (and red tape), some obvious, some not so obvious.
In this post we're going to have a look at some of the issues / requirements you might face.
Here is a list of some of the things you can check:
PIA (Primary Interop Assemblies)
The PIA needs to be installed/registered on the target machine
Note: You will notice if you use any of the office interop's the setup includes the PIA assemblies within the "Detected Dependencies"
of your setup - you will need to exclude them (right click on the assembly, click on exclude), since we're going to use the
assemblies registered/installed to the GAC.
It makes sense to include PIA as prerequisite in your setup.
Click here for
Handling exceptions in our add-in is paramount.
Office applications disable add-ins that misbehaves, there are two methods of disabling add-ins
- according to the severity of the misbehavior.
If an add-in causes Office to crash for example, the add-in gets hard-disabled, if an add-in crashes
without managing to crash Office, the add-in gets soft-disabled.
Its possible to re-enable the add-in via the Office interface,
or by changing registry entries.
For hard-disabled add-ins, one can simply delete the resiliency key, in the following key 12.0 is the office version, and
"Word" the office application.
For soft-disabled add-ins you need to set the LoadBehavior of an add-in from 2 (unloaded) to 3 (loaded), depending
on if the add-in was installed only for the current user or all users, you can find the LoadBehavior inside one of
the following keys:
During install an user's got the option to install the add-in for the all profiles or only
the current profile - which obviously makes the add-in unavailable to other profiles.
We need to ensure that all assemblies required to run the add-in is available, this is something
one can include in our primary output (if possible) of our setup or as a prerequisite.
Assuming that we're using .NET, we need to ensure that we've got the correct version of the framework
on the target machine - which we can include as prerequisite.
In the case of shared add-ins developed in .NET, you'll find that add-ins run on the mscoree which
is like an universal "shim" - which means that other add-ins running on this "shim" (same app pool) may
affect our add-in negatively.
It might become prudent to develop your own "shims"