The Case For Shared Add-ins
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.