Office 2007 New Extensibility Interfaces

Office 2007 introduced a set of new extensibility interfaces. Prior to Office 2007, there were several extensibility interfaces, which all behaved differently, required different development techniques, different deployment/registration and different runtime lifetime characteristics. These included ISmartTagRecognizer, ISmartTagAction, ISmartDocument and IRtdServer. The only interface that was usefully implementable in a COM add-in was IDTExtensibility2 – and, of course, the add-in had to implement this interface by definition.

One of the nice things about the new extensibility interfaces in Office 2007 is that they are all implementable in a COM add-in (either unmanaged or managed, and either a shared add-in or a VSTO add-in). This convergence is by design – its something that the programmability team in Office felt was particularly important in the evolving story of Office as a development platform. This design means that going forwards you only have to worry about one development model, one deployment model, and one runtime behavior model. The new interfaces are listed below – there are 8 of them (or 7 ½ depending on how you look at it - more on this below):

Why 7 ½? Well, IDocumentInspector is listed here for completeness – actually, it's an anomaly. You can implement IDocumentInspector in an add-in, but you can also implement it in a regular (non-add-in) class library or DLL. You don't have to implement it in an add-in. Office does not load a document inspector in the same way as an add-in – instead, it cocreates the class that implements IDocumentInspector using traditional COM registration. Indeed, if you do choose to implement this interface in an add-in, your add-in DLL will get loaded twice by Office – once through the normal add-in load path, and a second time when Office cocreates it independently.

All the other new interfaces are intended to be implemented in an add-in, and are used in the same way by Office. That is, Office loads an add-in and then queries the add-in to see if it implements each of the new interfaces. For each interface, if the add-in confirms that it does implement it, Office will subsequently make callbacks on the interface. This convergence on a single standard model is very refreshing. However, note that there are still some differences in the way that Office uses the interfaces. For example, Office queries the add-in for each interface at different times:

Another difference is that for all interfaces apart from IRibbonExtensibility, Office treats the interface as a standard COM interface. That is, Office only calls methods defined in the interface. For IRibbonExtensibility, on the other hand, Office treats this as an automation interface, and will make calls to any number of methods that you define in your object (and your Ribbon XML) but not in the IRibbonExtensibility interface. This "arbitrary callback" model is dramatically different from most other things in Office development, although it is similar to how the old ISmartDocument interface was used (and wasn't that a fun interface to work with? J).

In a previous post, Low-level support for ICustomTaskPaneConsumer, IRibbonExtensibility, FormRegionStartup, etc, I talked about how the VSTO runtime supports the new extensibility interfaces as part of its low-level infrastructure. Note, however, that VSTO only supports 3 of the new interfaces: ICustomTaskPaneConsumer, IRibbonExtensibility and FormRegionStartup. The other interfaces may or may not work with the VSTO runtime, but we have not done any extensive testing on them, so we cannot support them. Also, of course, VSTO provides both design-time and runtime support for the 3 supported interfaces at a higher level, in addition to the low-level support – and it's obviously easier to use the higher-level support wherever it meets your needs. You can also mix the high and low level support if you want to – for example, use the high-level support for custom task pane and the low-level support for Ribbon customization in the same add-in. The underlying Office interface querying mechanism and the VSTO low-level infrastructure are both designed to be open-ended. That is, the design should support any new interface that Office might introduce in later releases.