Although there are a lot of components and features in VSTA, I think that most of us on the VSTA team tend to lump those features into three buckets: SDK tools, runtime and designtime. Today, I’ll focus on the runtime components of VSTA and the various ways to use them to load add-ins into a hosting application.
The main component of the VSTA is “The AddInManager,” which is a group of classes that are used to manage add-ins. It is an interesting aspect of the way our design evolved that there isn’t actually a type called “AddInManager.” Instead, the AddInManager consists of several discreet classes. The most basic of these are the AddIn, AddInCollection, and Context classes. All of these are packaged in an assembly named Microsoft.VisualStudio.Tools.Applications.AddInManager.dll and are in the Microsoft.VisualStudio.Tools.Applications namespace. There are many classes in the AddInManager, mostly used in more advanced scenarios that we’ll see later.
So, what are each of these classes? Basically, the AddIn class represents an assembly containing entry-points that compose a user-created add-in. In most cases, the assembly will be the output of the VSTA project that was built by the end-user in either the VSTA or VisualStudio IDE. This is probably the most important class in the Add-In Manager, at least in simple scenarios.
The AddInCollection and Context classes are basically collections that contain add-ins. The Context class is used to define behaviors that are common to all of the add-ins it contains, such as the HostItemProvider and the Evidence used if any AppDomains need to be created. The AddInCollection class is just that: a collection of add-ins. Quite honestly, we had some larger ambitions for the AddInCollection class that didn’t make it into the v1 release due to scheduling restraints, although we left the design open enough to be able to add them in future versions.
In my next post, I’ll examine these classes further and show how they can be used to customize the load an unload behavior of add-ins for different scenarios and to achieve differing levels of resiliency, security and performance.
Aaron HareSoftware Design Engineer