Share via

The Case For Shared Add-ins

  • Article

People have been building native shared add-ins for Office (and related apps) since their introduction in Office 2000. People have been building managed shared add-ins since the introduction of .NET in 2002. VSTO support for managed add-ins was introduced in 2005. It is clear that the strategic technology choice is managed code, and for Office add-ins it is VSTO. For a discussion of the main reasons why traditional managed add-ins (aka shared add-ins) are problematic – and how VSTO add-ins address these problems – see this MSDN article on the architecture of the original VSTO 2005 Outlook add-in support.

So, are shared add-ins dead? Not really: you still need shared add-ins in the following cases:

1. If you want (or need) a single add-in that targets multiple apps directly.

2. If you want (or need) to build in native code.

3. If you’re targeting Office versions prior to Office 2003.

4. If you’re targeting Office apps that VSTO doesn't support.

5. If you’re targeting non-Office apps that support the same COM add-in model (such as MapPoint).

6. If you want a very minimal runtime dependency apart from the CLR (and specifically want to avoid the overhead of the VSTO runtime).

Let’s examine each of these in turn. For #1, you can easily satisfy the requirement to target multiple hosts with VSTO add-ins by building simple app-specific shell add-ins which delegate all the real work to some common DLLs. This is likely to be a better architecture anyway – in terms of simplification of design, logical abstraction of functionality, functional separation of components, and component re-use.

For #2, it is true that developing in a native language such as C/C++ is more difficult (and more error-prone) than building in a managed language – and this is a significant factor in the success of VSTO, which only supports managed add-ins. However, there are several reasons why native code is often preferred, notably:

ú The organization may already have a large library of native domain-specific code that will be called by the add-in, and they don’t want to take the dev/test cost of calling out through p/invoke. The most commonly-quoted example is quants libraries used in Excel add-ins.

ú If the organization can completely control which add-ins are installed in the enterprise, they have the option to eliminate managed code from Office hosts. They might want to do this to avoid the admin overhead of deploying/managing the CLR, additional admin for managed code, and the perf (and working set) hit of loading the CLR into an Office process.

ú Apart from the up-front perf hit from loading the CLR, managed add-ins will generally perform slower than native add-ins – especially if they make chatty calls to the native host OM via the PIAs, because of the overhead inherent in COM interop.

You could argue that #3, #4 and #5 are really variations of the same constraint – the need to build an add-in for (a particular version(s) of) some (Office or non-Office) application that VSTO does not support. As we know (see here and here), you can morph a VSTO project for a supported application into a project for an unsupported one – but the key is that this is unsupported – and most enterprises and ISVs are justifiably reluctant to wander into unsupported territory.

#6 is almost a circular argument: you want to use a shared add-in because you don’t want to use the alternative (VSTO) add-in type. Nonetheless, it is a valid requirement. The VSTO runtime is relatively small (about 0.5 Mb runtime), but still bigger than the alternative. (The alternative “runtime” for managed add-ins is the COM shim, which is tiny in comparision to the VSTO runtime).

So, while issue #1 is not really a problem, the remaining 5 are. In mitigation, the landscape is changing. Specifically, you can expect to see VSTO supporting more and more applications in the future – certainly within the Office suite, and potentially outside also. Note, however, that this will not be retrospective – you’ll likely never see VSTO supporting apps prior to 2003, for example (this might technically work, but it wouldn’t be supported – because it is untested). Bottom line: there are cases where you cannot use VSTO and you must therefore use shared add-ins, and this will likely always be true.

Comments

  • Anonymous
    May 09, 2008
    PingBack from http://library.xltblog.info/?p=11802
  • Anonymous
    May 11, 2008
    Thanks for the article.. do you think you could ever use VTSO with the MapPoint CD product?Eric
  • Anonymous
    May 12, 2008
    Eric - we'd like to support as many host applications as possible, including MapPoint and others - but it always comes down to test coverage. That is, we only support scenarios that we can properly test, and there is always competition for test resources. So, we would like to support MapPoint, but I can't say when that might happen.
  • Anonymous
    May 14, 2008
    Hello,I am writing a blog about VSTO in Chinese.I would like to get support from you. SO could we exchange links,and I would like to translate some articles of yours.My blog is http://www.5ushare.com/index.php.Thanks very much.                           Yours Charlie
  • Anonymous
    May 16, 2008
    Charlie - thanks for your interest. We've had a couple of requests like ths before, and we're looking into how best we can move forward on this. Someone from my team will get back to you on this shortly.