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 (23)
  1. The Microsoft Trinity team, which is responsible for the VSTO and VSTA products, is transferring the…

  2. What is an Application Domain (AD)?

    An Application Domain is a CLR feature that provides a unit of isolation…

  3. This was my first webcast, so please be patient through the beginning.&amp;nbsp; It gets much better there…

  4. You may be asking, &amp;quot;Is thisproxy layer stuff really necessary? Why do I have togenerate proxy types

  5. VSTA&amp;#39;s run-time assemblies implement 2-way, version-resilient, secure, and robust coommunication

  6. TAM v2.1 introduces a new security model for the plug-in under which the behavior of the plug-in can

  7. VSTA’s run-time assemblies implement 2-way, version-resilient, secure, and robust communication between

  8. ... says:

    Lavoro eccellente! ..ringraziamenti per le informazioni..realmente lo apprezzo: D

  9. Jeremy Haiile says:

    Any idea where I can obtain the System.AddIn Class Libraries?

    I do not have them in my version of Visual Studio

  10. Jeremy, Check out the following post on "where can I get the bits" – http://blogs.msdn.com/jackg/archive/2007/03/01/secret-revealed.aspx

  11. We have gone through some naming changes with WinFX and .Net . And we have gone through a few on the

  12. What is an Application Domain (AD)? An Application Domain is a CLR feature that provides a unit of isolation

  13. Okay, so in previous post we tried to understand basic needs for being connected with our People and

  14. Praveen says:

    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.

  15. Praveen, Yes. Just ensure your contract assembly is discoverable. Jack

  16. unknown says:

    Where can I get this?

    The link above is out of date.

Comments are closed.

Skip to main content