Managed Add-ins for Office
We did some work a while back to support managed add-ins in Office by ensuring appdomain isolation. We provided some VS wizards that generate unmanaged C++ code for a shim component that you register with your add-in. All this works pretty well, but it is not actually a supported product. Also, there was heavy redundancy, because you had to build one of these shims for each and every add-in (even though almost all the shim code was the same across all add-ins).
So we looked long and hard at this, and decided that we needed to increase the level of support we provide for developers building managed add-ins. Today, we release (in beta) a new set of projects for Visual Studio 2005, that specifically target managed add-ins for Outlook.
The release includes both design-time and runtime pieces. At runtime, a dedicated add-in loader component (AddinLoader.dll) ensures that each add-in is loaded into a separate appdomain, that strict security policy is enforced, and that the add-in is unloaded when it is disconnected.
This component essentially bootstraps the VSTO 2005 runtime, and it is the runtime that does all the heavy lifting of reading add-in manifests, checking for updates, checking security policy, creating appdomains, and loading the target add-in. The runtime is the same runtime that is used in VSTO 2005 document-level customizations for Word and Excel. This kind of component re-use is generally a good thing.
It also means that your add-in code has much in common with VSTO document customization code. For example, the new project will generate code that is specific to Outlook - you get a base class that represents the Outlook Application object. This is the same idea as in Word and Excel projects where you get a class that represents the Document (or Workbook and Worksheets). This means that you have a strongly-typed object to program against, with all the design-time benefits such as Intellisense and auto-complete.
Just as with document-level customizations, this class implements the IStartup interface. Therefore, the AddinLoader component also provides a mapping between the IDTExtensibility2 interface that Office expects to talk to, and the IStartup interface that the VSTO runtime expects to talk to.
The net result is a single reusable shim that Microsoft ships and supports (instead of every developer building his/her own), a cleaner programming model, and a robust runtime. I'd be very interested in getting feedback on this.
Full details are in this article:
Architecture of the Outlook Add-in Support in Visual Studio 2005 Tools for Office