Back To The Future

Or, Prototyping VSTO Add-ins for Unsupported Office Versions/Applications

It is in the nature of the VSTO 2005 SE and VSTO 2008 add-ins that they will run in multiple versions of Office. One of the main reasons for designing them this way is to mitigate the disconnect between the Office ship schedule and the Visual Studio ship schedule. Each version of Visual Studio provides tools support for the version(s) of Office that exist at the time it is released. Clearly, any given version of Visual Studio cannot provide tools support for versions of Office that don’t yet exist.

This is one of the primary reasons for the VSTO 2005 SE release. When Visual Studio 2005 (including VSTO 2005) shipped, the latest Office version in existence was Office 2003, so Visual Studio 2005 could provide tools support only for Office 2003. Office 2007 was released before the next version of Visual Studio. This is where VSTO 2005 SE comes in: this release provides support for Office 2007.

The general pattern is that the next version of Office after Office 2007 (say, Office "14") will ship after Visual Studio 2008 but possibly before Visual Studio "2010". This means that customers might want to build add-ins for Office "14" before there is specific tools support.

The idea is that – for prototyping, at least – you could in theory create an add-in for Office "14" by creating an add-in for Office 2007 and then tweaking it slightly so that it works with Office "14". Of course, you would have no tool support for any new features in Office "14", but you would be able to build prototype add-ins for Office "14". You wouldn't do this for production add-ins, because the technique is not supported, but it would be invaluable for proof-of-concept scenarios.

This new extensibility model introduced in Office 2007 also lends itself to open-ended prototyping. The use of the VSTO RequestService mechanism means that an add-in can implement any new extensibility interface, and the existing runtime implementation of RequestService will accommodate it. I should stress again that while the technology enables this technique, Microsoft does not support this: we cannot support this because we cannot test it (how can you test a future release?).

The corollary of this is that it is possible to create a VSTO 2005 SE or VSTO 2008 add-in project without necessarily having all the pre-requisites on the machine. From the VSTO 2005 SE release, VSTO does not block project creation even if you don’t have either the target Office application on the machine, or the target Office PIA on the machine. This might seem strange, but it's a deliberate strategy to accommodate prototyping scenarios.

In some cases, this will result in projects that will not build until you take some manual remedial action. This action would typically be to change the PIA reference. Or possibly, you could install the version of the PIAs that you are targeting, and so on. It may seem like a poor user experience to allow you to create projects that are initially "broken", but the point is that this does allow you to create projects for Office versions that Visual Studio has not yet released tool support for.

The original VSTO 2005 Outlook add-in ThisApplication base class used the same model as VSTO 2005 doc-level projects. This model involved wrapping the Office OM objects. For doc-level projects, this made sense because the VSTO runtime provides additional functionality around the indivdiual objects. For add-ins, it made less sense because we only provide very minimal enhancements. At the time, we wanted to keep the add-in design the same as the doc-level design, to ease the transition for developers moving from doc-level customizations to add-ins.

For VSTO 2005 SE and VS 2008 we introduced a new add-in base class, which is different from the old VSTO 2005 Outlook add-in project and different from the doc-level projects, but it allowed us to make each of the add-in projects essentially the same. That is, the add-in base class for Outlook is 99% the same as the add-in base class for Excel, for Word, for InfoPath, PowerPoint and Visio - in other words, they're all almost identical clones.

So, this new add-in model makes it easy to prototype add-ins for Office host applications that are currently unsupported, and also to prototype add-ins for versions of Office that are currently unsupported.