Share via


What is an Addin?

   Now that we know how to spell it, let’s define our terms. The definition of the word “Addin” it turns out is more complicated -- and is a sense more simple -- than I originally thought when I first started questioning it. Before that I had my own definitive notion of what an Addin was: an Addin was a COM object that implemented IDTExtensibility2 and was loaded into some Office app or Visual Studio. I “knew” this was an Addin because one of my first jobs at Microsoft was to work on the Addin Designer. And the designer obviously produced addins, and that's what they were.

   But a couple years ago I got pulled into a planning committee for Longhorn – oh, sorry, Windows Vista – to talk about a unified Addin model. It was a huge committee; there were representatives from all over the company, several from the Developer Division, many from all over Windows, and many others from Office. I quickly learned that that all of these people had different conceptions of the word “Addin.” Heck, Office itself has at least 4 or 5 things that qualify as Addins – and VSTO is adding more. The one that took me most aback, though, was when a guy from the IE team started referring to ActiveX Controls as Addins. That one was an eye-opener – I had put ActiveX Controls into a separate category mentally. But I realized that for him, they were his Addins – they are dynamically discovered and loaded components.

   So that gets us close to the definition. My definition of an Addin is as follows: 

An “Addin” is any component that is dynamically discovered and loaded by its host. It usually is compiled separately from the host and the host and Addin version independently of each other. The host and addin must agree upon a common contract or contracts through which they communicate.

   This definition is deliberately broad. I learned that my concrete Addin conception was just one particular kind of addin. So are ActiveX Controls. And SmartDocuments in Word. And Shell Extensions in Windows. The list goes on, and the definition, hopefully covers them all. 

   But, the definition above requires the definition of a few more things: component, host and contract.

   Component is a similarly tricky thing to define. Everyone has a preconceived notion about just what a “component” is. I don’t presume to have the definitive notion of component here, but nonetheless, it must be defined. So for the purposes of this article, and this blog in general:

A component is a discrete unit of functionality, usually conceived as an “object” or set of objects conforming to an object-oriented model.

   OK, is that vague enough? Basically it is a chunk of code that does something specific. I included the object-oriented bit because that’s how I think of it.

   The “host” in the Addin definition is easier to nail down. The “host” is the thing that the Addin adds in to. (Or should I say “the thing to which the Addin adds in.”) It can be an executable – the app – or another addin. Yes, Addins can have addins.

   And finally, the “contract” is just that – a previously decided upon method of communication with rules and limitations. Contract is deliberately vague here as well, but we’ll see that in practice the rules around contracts for addin communication become very specific. For all of the examples of Addins I listed above, in the COM world, contracts manifest themselves as COM interfaces. .NET has interfaces too, but as we’ll see in future articles, the rules for contracts in .NET are even more constrained.

   So, what is an Addin then? It is virtually any component that is loaded into your app that you don’t control directly: any component that can get loaded into your app when it is “in the wild.”

Comments

  • Anonymous
    September 13, 2005
    Couldn't an add in be, a web part in .net or a portal control in sharepoint as well. By this definition thats exactly what it is. Are those going to be unified as well? And do you think we will see this this in the next version of Visual Studio or will this be an Add-In to the current Add-Ins in VS 2005.

    Hmm you know your job on Add-Ins is almost like an Infinite Loop. You can have an Add-In to Sharepoint, that produces an active X control which would be an Add-In to IE, which then could also install an Add-In to the Operating System. ;-) Thats a lot of Add-Ins. However good blog topic, I like to create Add-In's not professionally for tools but for apps where I just find some missing functionality. Looking forward to some more. BTW will you hopefully be discussing some coding techniques and example on current Add-In architectures.

  • Anonymous
    September 13, 2005
    Yes, you are correct. Addins are everywhere. I am going to discuss techniques both here and at my PDC talk tomorrow. We will be announcing some exciting new technology, so stay tuned.

  • Anonymous
    September 15, 2005
    This is an excellent question posed by TQ, one of our architects, on his blog. The definition of an add-in...

  • Anonymous
    September 15, 2005
    This is an excellent question posed by TQ, one of our architects, on his blog. The definition of an add-in...

  • Anonymous
    March 21, 2007
    The VSTA SDK samples and VAO include code for ‘Macros’ and ‘Addins’, but It’s really nothing more than

  • Anonymous
    June 09, 2009
    PingBack from http://insomniacuresite.info/story.php?id=4122