Origin url: http://blogs.msdn.com/andreww/archive/2006/02/18/converging-the-office-add-in-model.aspx
Over the years, Office has exposed a number of different extensibility mechanisms, which all enable developers to build solutions based on Office. Each of these mechanisms is geared towards a different set of requirements, and the design of the extensibility interface reflects these different requirements.
Think of the options: COM add-ins, XLLs and WLLs, XLAs and DOTs, automation add-ins, realtime data servers, Excel UDFs via XLLs, smart tags, and smart docs. For each of these technologies, you have a partially overlapping set of development language options: VBA, VB6/C/C++, and managed code. Also a range of choices for toolset: automation, declarative XML (MOSTL), the web services toolkits, the accessibility interfaces, COM/.NET interop via the PIAs, and VSTO.
This is all well and good, but there is one drawback: inconsistency. For example, consider that the way you develop a smart tag for Excel is completely different from the way you develop a UDF for Excel (plus, you have 3 different ways to develop a UDF). It is good that Office has exposed a range of precisely-scoped programmability interfaces, but the time has come to bring some order to the offering.
This is one of the many ways that Office 2007 improves on the past. All the new programmability features in Office 2007 are designed to use the same development model as far as possible (allowing for differences in the Office applications themselves). These new features include custom taskpanes, ribbon customization and Outlook custom form regions.
Q: How do you develop an app-level custom taskpane?
A: Build an add-in.
Q: How do you develop an app-level custom ribbon?
A: Build an add-in.
Q: How do you develop an Outlook custom form region?
A: Build an add-in.
Designing this model for all new programmability features is a big step forward. You might ask, what about the old programmability features? Why can't I build a smart tag by building an add-in? Why can't I build a UDF by building an add-in? The anwer is that retro-fitting this model to existing interfaces is problematic. If we change the way Office loads smart tags and UDFs, what would happen to all the existing smart tags and UDFs that use the old model? It may be that over time, even the old programmability features can be brought into the brave new world. Maybe we could engineer it so that new smart tags are add-ins, and old smart tags still work the same way they did. This is a longer-term question, and it would be interesting to get feedback from the industry as to how useful this might be.
For now, the significant message is that VSTO is the default toolset for building Office solutions going forwards, and add-ins are the primary mechanism for implementing custom functionality for Office.
