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.”