PDC05 - Managed AddIn Framework (MAF)
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.
Comments
Anonymous
February 06, 2006
The Microsoft Trinity team, which is responsible for the VSTO and VSTA products, is transferring the...Anonymous
March 07, 2006
PingBack from http://blogs.msdn.com/jackg/archive/2005/10/31/487343.aspxAnonymous
March 07, 2006
PingBack from http://blogs.msdn.com/jackg/archive/2005/09/15/468080.aspxAnonymous
March 08, 2006
PingBack from http://blogs.msdn.com/jackg/archive/2005/09/14/466721.aspxAnonymous
March 10, 2006
What is an Application Domain (AD)?
An Application Domain is a CLR feature that provides a unit of isolation...Anonymous
April 24, 2006
This was my first webcast, so please be patient through the beginning.&nbsp; It gets much better there...Anonymous
July 31, 2006
You may be asking, &quot;Is thisproxy layer stuff really necessary? Why do I have togenerate proxy typesAnonymous
August 18, 2006
VSTA&#39;s run-time assemblies implement 2-way, version-resilient, secure, and robust coommunicationAnonymous
October 30, 2006
TAM v2.1 introduces a new security model for the plug-in under which the behavior of the plug-in canAnonymous
January 24, 2007
VSTA's run-time assemblies implement 2-way, version-resilient, secure, and robust communication betweenAnonymous
February 23, 2007
Lavoro eccellente! ..ringraziamenti per le informazioni..realmente lo apprezzo: DAnonymous
March 10, 2007
Any idea where I can obtain the System.AddIn Class Libraries? I do not have them in my version of Visual StudioAnonymous
March 11, 2007
Jeremy, Check out the following post on "where can I get the bits" - http://blogs.msdn.com/jackg/archive/2007/03/01/secret-revealed.aspxAnonymous
March 14, 2007
We have gone through some naming changes with WinFX and .Net . And we have gone through a few on theAnonymous
November 05, 2007
What is an Application Domain (AD)? An Application Domain is a CLR feature that provides a unit of isolationAnonymous
February 02, 2008
Okay, so in previous post we tried to understand basic needs for being connected with our People andAnonymous
March 29, 2008
PingBack from http://copyrightrenewalsblog.info/microsoft-application-threat-modeling-blog/Anonymous
June 16, 2008
PingBack from http://blogs.southworks.net/jcisneros/2008/06/16/managed-add-in-framework/Anonymous
July 28, 2008
We are using the .NET application Addin Programming model to develop Addins. Our application has lots of Addins. I have read that all the Contract extend from IContract. We would like to have a base contract for our applicaiton from which the contracts for all our Addins extend for example IPlugin : IContract IMyCalcV1 : IPlugin IMyCalcV2 : IPlugin Is is this do able.Anonymous
August 04, 2008
Praveen, Yes. Just ensure your contract assembly is discoverable. JackAnonymous
August 12, 2008
PingBack from http://hirentechie.wordpress.com/2008/08/12/managed-addin-framework/Anonymous
January 13, 2009
Where can I get this? The link above is out of date.Anonymous
February 03, 2009
PingBack from http://jtesolutions.wordpress.com/2009/02/03/3/