Office Shared Add-ins: Issues - Part 1

November 29, 2010 by Christoff Truter Microsoft Office  

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:

1. PIA (Primary Interop Assemblies)
   
   The PIA needs to be installed/registered on the target machine
   Office 2003 | Office 2007
   
   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 more information.
   
   
2. Disabled
   
   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.
   
   

   HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Word\Resiliency

   
   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:
   

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Word\Addins\SomeAddin

   HKEY_CURRENT_USER\Software\Microsoft\Office\Word\Addins\SomeAddin

3. Profiles
   
   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.
   
   
4. References
   
   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.
   
   
5. Other Add-ins
   
   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"