Microsoft Office, MSDN, Extensibility (Add-In’s)
We recently published an article on the new CLR System.AddIn libraries in the February 2007 MSDN magazine. As I looked at the magazine cover I was *amused* by the coincidental irony of an issue that proudly announced not 1, but 3 separate Add-In solutions.
1. CLR Inside Out - .Net Application Extensibility
2. RibbonX API (A COM Add-In for Excel)
I suppose this is further evidence of the demand and importance of application extensibility. This plethora of solutions however, contributes to customer confusion. This is the primary reason why I have been pushing for a unified model, freely available in the platform, for use by Microsoft products, as well as customers offering application extensibility.
Four solutions
Wait a minute – didn’t you just say 3. Is this a zero or one base issue again ;-) Each solution evolved from the previous and each subsequent solution usually offers enhanced functionality. Software, like fine wine, should get better with age.
1. The COM model
In the beginning, Office realized the value of extensibility, as well as the benefits of a COM interface model. However, utilizing an undefined COM interface model leads to customer complexity, lack of uniformity, etc… As a result, Office drove the definition of a “standard” interface definition for external application automation. This definition was called IDTExtensibility. Subsequent to this, they refined this interface into the present day IDTExtensibility2. I’ll defer talking about why a pure interface based model is inadequate (e.g., Immutability without adaptation, Up/Down Casting, etc..).
2. Managed (.Net) Shim
With the advent of managed code we discovered the need for interoperability between managed code and COM. Interop gives us the ability to retain our legacy code base while moving forward. In order to enable (and simplify) developers to write managed (i.e., C#, VB.Net, IronPython, ...) Add-In’s against an unmanaged COM Object Model, the Microsoft Visual Studio team built project templates for creating a managed project for IDTExtensibility2.
You can see what I am talking about by opening Visual Studio, Select File, New, Project, Other Project Types, Extensibility, Shared Add-In (VS installed templates), select the application(s) to extend (e.g., Word, Excel,..).
3. VSTO (Visual Studio Tools for Office)
When I was the Development Manager for the VSTO team it was one of my primary objectives to enhance the Office Application (i.e., App level) extensibility offering in order to provide a more robust managed code experience. We actually delivered the Outlook (customer demand was overwhelming) Add-In project in the Whidbey (VS 2005) product. You can read about some of the VSTO additional value added on top of the VS Shim project on MSDN.Recently the VSTO team used this code base to offer a breadth of Office Add-in’s, (Word, Excel, Powerpoint, Visio, …).
You can see what I am talking about by opening Visual Studio, Select File, New, Project, Visual C#, Office, Outlook Add-In (VS installed templates).
4. CLR Add-In model
The CLR Add-in model is the evolution of the work we did for Visual Studio Tools for Applications (VSTA). I was also the Dev Manager for the VSTA v1 product. The Trinity team owns both the VSTO and VSTA products. You can think of VSTA as the managed version of VBA. Here is a link to a post on FAQ’s on VSTA and the CLR Add-In model. I will be updating the post with the latest information on what is now shipping in the CLR Orcas release.
The CLR MAF (Managed Add-In Framework) is now available for ISV’s and developers for inclusion in your products for enabling a version resilient, isolatable managed object model. Keep in mind that you can build this on top of your COM object model. The CLR Add-in model provides Add-In discovery, activation, lifetime management, and a design for your object model to enable isolation, remoting, and version resilience.
When VSTO moves over (I can’t guarantee when) to using the CLR Add-In model you will inherently be using the CLR implementation under the covers of the VSTO Office projects they generate. VSTO host extensibility is offered via the PIA’s as well as the VSTO product extensions they add to the Host Office applications (e.g., Task Pane). Therefore, the discovery, isolation, activation and VSTO extensions should be built upon the CLR Add-In model.
At some juncture (hopefully soon) VSTA will also reconcile their MAF implementation with the CLR implementation (more on this later). I expect the VSTA product will offer its current generic adapter MAF implementation as well as a custom contract model based upon the CLR implementation. The discovery and activation within the VSTA Add-in manager may also be built in part on the CLR offering, but I’ll leave that to TQ to determine.