Managed Word Add-in: The Initial Design

Introduction

The Options

Following are the options to write a managed Word add-in:

1. VSTO: VSTO is a great tool. Many complicated tasks like shimming are taken care inherently by VSTO (Orcas). VSTO Word add-ins are scoped to document level and template level, but not application level.
1. Word Document: VSTO provides a 'Word Document' template (in VS) to create a Word add-in. The code that is written here is more or less like VBA, with the added advantage of full access to the Framework Class Library (FCL). This code is associated only with this particular document, and doesn't run for any other Word document.
2. Word Template: VSTO provides one more template, 'Word Template'. This provides a more generic solution than the previous option. The basic idea is to write all the code in this template and place this template in the STARTUP folder of Office. This results in loading of this template for each document that is opened/created and thus, the code runs for the document.

The base line here is to use VSTO when the solution (add-in) needs to be scoped at the document level or the template level. Though there is more flexibility at the template-level add-in, there are a few things that this approach can't achieve, like loading of this template selectively for some documents.

2. Shared add-in: If the Word add-in needs to be running at application level, use the shared add-in approach. 'Shared Add-in' is a template that is provided by VS, and doesn't require VSTO to be installed. Add-in created using this approach inherits from the IDTExtensibility2 interface. This is the crux of this approach.

Shared add-ins run on each of the documents that is opened or created on the machine. This is the scoring point of the shared add-in over the VSTO approach, though there are a few things that need to be taken care of by the developer and are cumbersome (the trade-off).

The Winner

As a thumb rule in any design exercise, there are no winners. The same applies here.

Use VSTO when:

• As already mentioned, your solution doesn't need to be at an application level and doesn't need higher flexibility (like running code while the Word application connects to the add-in or finishes the connection etc.).
• You need the added advantages of managing the shimming inherently (shimming is very important and a painful process, especially if the developer doesn't have knowledge of C++). Not only shimming, but also many small things that need to be managed by the dev in the shared add-in approach are built-in here, like adding a transparent icon to a command bar button.
• In many of the cases, the 'Word Template' approach does the trick, unless one wants to meddle with the template itself. For example, if on a conditional check you want to remove the template that you have your code in, i.e., you don't want the add-in to run, you can't delete the template as it is present in the STARTUP folder. This kind of flexibility is available only in the shared add-in approach.
• You don't want to worry about the Office version compatibility. VSTO supports all Office versions from and after Office 2003. So, the developer need not worry about making the add-in compatible to all the versions.

Use the shared add-in approach if:

• Your solution needs to be at an application level, i.e., you need the code to run on each of the documents.
• You need more flexibility and access to the startup process of both the add-in and Word.
• You can make your add-in work on any Office version from and after Office 2000 (there was no add-in concept before that), though it requires additional work.
• But be aware that there can be many hiccups before the solution can be deployed successfully on end-user machines, especially if they are clean machines.
• Hiccups like shimming, not being able to remove the toolbar/menu that is added, adding transparent icons to command bar buttons and menu items, on the development side.
• On debugging side, you need to attach WINWORD.EXE to VS for being able to debug. But by the time you start Word and come to attach it into VS, all your startup code would have been executed.
• On the deployment side, all the updates need to be installed before the add-in is run or the add-in might get disabled. And the bad news is that the reason for it being disabled will never be communicated to the user.

But there are solutions for each of these issues and are implementable, though not very easy.

On the whole, the VSTO solution is very specific while the shared add-in approach is more generic. Eventually, the decision depends on your requirements.