Converging the Office Add-in Model

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.

Comments

• Anonymous
  February 18, 2006
  Aa little sad that .MDA files for Microsoft Access were not included, but maybe the fact that you pointed out all of the problems with things on the list will make the omission seem like a good thing for them? :-)
• Anonymous
  April 10, 2006
  I have posted a <a href='http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=342678&SiteID=1">question</a> about Excel COM add-in vs. Managed Automation addin at the <a href='http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=342678&SiteID=1">MSDN's VSTO Forum</a>.  Will you be kind enough to provide some insight?  Thanks!
• Anonymous
  September 25, 2008
  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
• Anonymous
  June 29, 2009
  Hi Andrew Whitechapel.I am new to UDF development for Excel, and I am trying to get a hold of the different ways to make UDFs. In this blog post you say that there are three ways to do this, do you mean:1) Visual Basic editor in Excel2) COM Automation3) XLLIs this accurate? or are there more UDF-ways? I've had some trouble finding out is if it is possible to create UDF's through COM Add-ins (that is without automation, or to rephrase my question: was it possible to create UDF's with COM add-ins before automation was introduced?), since some sites call automation's for COM add-ins (thats my theory at least that they actually mean automations).Another problem I've been having is where to put the "Share Add-in" project type from Visual Studio in this context - is it a COM add-in, an automation or both - or something else?Thanks beforehand :-)andershh
• Anonymous
  June 29, 2009
  andershh - yes, those are the 3 ways to create UDFs that I meant. You could further subdivide Automation add-ins into managed vs unmanaged. (You could do the same for XLLs, although writing managed XLLs involves either a 3rd party library or a huge amount of work.)Excel Services also supports UDFs, using a different technique, so that adds another dimension.To your second question, no - COM add-ins should not be used for UDFs - because if you do use a regular COM add-in to expose UDFs, you can only do so by exposing it as an automation add-in - which means it gets loaded twice. So, you surmise correctly - when people talk about UDFs in COM add-ins, they really mean UDFs in automation add-ins.The VS Shared Add-in project type creates a regular managed or unmanaged COM add-in. For more details on building managed automation add-ins, see here: http://code.msdn.microsoft.com/managedUDFs