Share via

Back To The Future

  • Article

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.

Comments

  • Anonymous
    January 28, 2008
    PingBack from http://msdnrss.thecoderblogs.com/2008/01/29/back-to-the-future/

  • Anonymous
    February 01, 2008
    Following on from my previous post , it should be clear that we've designed the VSTO Office add-in support

  • Anonymous
    February 01, 2008
    Following on from my previous post , it should be clear that we've designed the VSTO Office add-in

  • Anonymous
    April 19, 2008
    Hi Andrew,I am developing an Outlook add-in for v2003 and v2007 in VS 2008 (C#). ClickOnce is not an option us for 2 reasons:The add-in used .NET remoting and requires access to the registry and file system;Having actually two add-ins is not an issue provided it is transparent to users who are offered a single setup experience. Our setup is designed as a Visual Studio setup project which currently installs both VSTO 2 and VSTO 3 as prerequisites. Since we are not using ClickOnce, I am wondering whether we could simplify the installation process by targeting only VSTO v2 (VSTO 2005 SE). Is this possible? Is there a way to tell VS 2008 to target the Outlook 2007 add-in project at VSTO 2005 SE?Please provide some guidance.Jacques

  • Anonymous
    April 20, 2008
    Hi JacquesThe short answer to your question is "No". When you ask VS2008 to create an Office 2007 project, it will always create a VSTO v3 project - this will include all the project metadata settings, version-specific DLL dependencies, PIA dependencies, and version-specific code-generated base classes etc that are tied to VSTO v3. The only way to convert this project to work with VSTO v2 is to rip out pretty much everything so that you have a v2 project - in which case, you might just as well have started with a VSTO 2005 SE v2 project in the first place.Note that for an Outlook add-in, what a v3 project gives you over a v2 project is basically 3 things: custom Ribbon wrapper/designer, custom form region wrapper/designer, and ClickOnce support. The Ribbon and form region wrappers/designers are a RAD convenience - you can do everything they do manually if you need to.For an alternative approach, consider a single add-in with version-specific functionality in separate assemblies. See here for details: http://blogs.msdn.com/andreww/archive/2007/06/15/can-you-build-one-add-in-for-multiple-versions-of-office.aspx

  • Anonymous
    April 21, 2008
    Andrew,Thank you for having taken the time to give such a comprehensive answer.I did read your article about one add-in for multiple versions of Office. We did not go that route for at least two reasons:1) Our add-in is quite complex and we did not want to go into unsupported territories at least for v1;2) Having two versions of the add-in is not an issue in our opinion provided it is transparent to users who are only confronted to one single setup (you cannot imagine the number of users who do not know the version of Office they use!).Development of the add-in is code complete and does not use any of the VSTO v3 features, so I agree we could have built a VSTO 2005 SE v2 project in the first place, but note that such a project is upgraded when opened in VS 2008 which does not make it a viable solution on the long run.As a conclusion, it seems that a single setup for both add-ins would need to deploy the two version of Office PIAs and the two versions of VSTO as prerequisites, then deploy the relevant version of the add-in, which makes a more complex setup than I would have expected.Thanks,Jacques