Share via

PDC05 - Managed AddIn Framework (MAF)

  • Article

MAF (Managed AddIn Framework)

The Managed Add-in Framework defines a programming model, built on top of .NET that allows applications to dynamically load and communicate with generic components at runtime. We provide a solution for creating independently versioning, mutually distrustful components, and allow them to work together. We tackle the two problematic – versioning and isolation – together.

At PDC05, Thomas Quinn, an architect on our team, responsible for VSTO and VSTA, and Jim Miller, a CLR architect, responsible for several platform components related to versioning support in the CLR, among other things, jointly presented the platform framework for managed Addin’s. See the PDC FUN309 session.

What is an Add-In?

An add-in is traditionally thought of as custom code (a customization), written by a third party that is loaded and activated by a Host application (Word, Excel, etc…) upon the host starting up. The host makes their programmable API (Object Model) available to the customization assembly. In the case of the Office host applications, the Application object, which is the root of the hierarchical object model, is made available to the Add-in. I will use “Addin” in a more generic sense to mean code that is discovered based upon some event (The host Starting up, the loading of a document, etc..). Later, I will argue that this definition is too narrow.

Behavior

Note that the definition I just articulated was a dynamic loading mechanism as opposed to static. An Addin is also generally loaded into the host’s process. This requirement then adds the concern of isolation. The host needs to be isolated from errant behavior of the Addin and Addin’s should in many cases, be isolated from each other. Although it is implied, the two components also need to agree on some communication protocol (a contract). 

An Addin should be able to be loaded/unloaded of its own accord or loaded/unloaded by the host.
The requirement to Load/Unload Addin’s dynamically, adds the further requirement that the Host and Addin need to version independently. 

A picture is worth a thousand words

 

Text image representation

Host Application - Adapter IContract | IContract - Proxy - Add-In

Host Process - Implements Contract IMyContra | ct : IContract - Addin Friendly facade/OM - Customization

                                     <-------------------------------------Direction of Call--------------------------------------------------------------

Vertical bar ( | ) represents a boundary (Process, AppDomain)

Terms

Contracts
Pre-defined interfaces used as explicit, agreed upon protocols for communication between two endpoints. 

• All user defined contracts derive from IContract the base interface.
• A Contract is roughly analogous to a COM Interface.
• Possibly a better description from Thomas Quinn (aka TQ), “A Contract is any .NET interface, derived from IContract (to be defined), and having the following properties: it never versions beyond servicing, the containing assembly contains only other Contracts or non-versioning types, and it exposes in its method signatures only other Contracts, or fully known, loadable, and serializable type. It explicitly cannot contain the types System.Object, System.Type, System.MarshalByRefObject, any type from System.Reflection nor delegates or events, nor any other type which may cause the exposure of an implementation type”

Adapters

• Implement contracts.
• Adapters serve the purpose of adapting between a friendly .NET Framework based programming model on each end and the less friendly, and more restricted contracts in the middle. Adapters are the object model.
• Similar in concept to web services. Although MAF is designed for Object Oriented services versus a Services Oriented model. We have worked with the Indigo team (aka. Windows Communications Foundation) on ensuring the two models are in alignment and they will continue to evolve in conjunction with each other. In a nutshell, both models prescribe an explicit understanding of boundaries (web service boundaries are machine), proxy generation, agreed upon contracts, separation of the definition and implementation and consumption, etc…

Proxies

• Consume (call into) contracts.
• Exposes an object oriented, .NET Friendly surface to its consumers (Add-in’s).
• Similar in concept to consuming web services.
• Makes requests across the App Domain boundary.

.Net platform libraries

System.AddIn.dll and the System.AddIn namespace

• The NS will first be made available to the public in the VSTA/O12 release in the second half of 2006.
• The VSTA product and MAF have been announced at PDC 2005.
• First available in VSTA/O12 and then made available broadly in Orcas as part of the platform (CLR).
• This System.AddIn.dll is the Add-in loader
• An Add-in is any component that is discovered and loaded at runtime by a hosting application and that version separately from the hosting application. The loader is the component that is responsible for the App domain creation utilizing a customizable security manager, loads and activates Addin's in specified App domains and provides Add-in unloading of specified App domains. The level of unloading in the CLR is by process or AppDomain.

System.Addin.Contract

• This dll may not version (first tenant of a contract).
• First available in VSTA/O12 and then made available broadly in Orcas as part of the platform (CLR),
• Defines base contract IContract
• Provides a remote kind of reflection. The contracts mimic the similarly named types in the System.Reflection namespace without providing the full implementation. The goal here is to be able to invoke methods and properties, set and get fields and handle events on objects across the remoting boundary without having direct access to that object’s Type. We provide a remote type surrogate that performs the duties of Type and its friends.