This posting is in response to a F.A.Q. (Frequently Asked Question) I receive regarding the Add-In model and Winforms.  To be clear, there is nothing in the Add-In model that prevents rich isolatable Host/AddIn UI scenarios. 

Support for AppDomains and/or Process boundaries enables unloadability and isolation but you need to be aware that this implies the demand for transcending the boundary with value or reference types via Serialization or Marshalling if you intend to allow types to cross the boundary.  The Add-In model supports both AppDomain and Process creation/isolation.  One way to ensure type transition, with support for isolation, avoiding type leakage, and enablement of version resilience, may be found in our definition of the constraints you place on a contract. 

In fairness to Winforms, MAF was not part of the platform when Winforms was designed and AppDomains were just becoming a viable option for many broad scenarios.

Let’s take a look at the Form Inheritance Hierarchy:

System.Object
   System.MarshalByRefObject
     System.ComponentModel.Component
       System.Windows.Forms.Control
         System.Windows.Forms.ScrollableControl
           System.Windows.Forms.ContainerControl
            System.Windows.Forms.Form

Unfortunately the full extent of the work to ensure marshalling for all inherited types and possibly more important, the members in the inheritance chain, was not completedL. 

What can you enable?

• You may have a Winforms Host that does not directly support Winforms UI composition across AppDomains but your object model may enable support across AppDomains via the Add-In model.
• You can create user forms in an Add-In that is isolated in a separate AppDomain from a UI Host AppDomain. 
• You can also build a bridge between the two by sending the requested functionality from the Add-In to the Host UI where the Host (and it’s AppDomain) performs the requested action.