Add-In’s (CLR and VSTA)

We have gone through some naming changes with WinFX and .Net. And we have gone through a few on the MAF (Managed AddIn Framework), the WinFX AddIn model and System.AddIn. The previous are all terms we use to discuss the Add-In model in the broad sense. I admit, with my carpel tunnel, MAF is a lot easier to type. So think of them all as the same thing.

That said, MAF has been a source of some confusion since the release of the Orcas CLR implementation. I am frequently asked if this is the same thing as the VSTA product or VSTA SDK offering. The answer is Yes and No J First let’s separate the MAF technology from the VSTA product - I previously posted some answers to questions on MAF vs. the VSTA product.

Now let’s answer the question of whether the CLR implementation of MAF is the same as the VSTA products implementation of MAF. The answer is Yes and No J You knew that was coming ;-)

Yes, they both base their implementation on the core fundamental component called a contract.

They both prescribe and adhere to the separation of integration and implementation, based on the contract and thus provide isolation, unloadability and version resilience.

So what’s the diff?

VSTA utilizes the System.AddIn.dll (v2.0) that shipped with the VSTA SDK. This is the dll that provides the AppDomain creation, Assembly loading, and Add-In activation. This dll was primarily provided for the VSTA Add-in manager, but customers could have used this dll as a nice clean wrapper on top of Add-In contracts. The API resolved a lot of difficult things to resolve if you tried to roll your own Add-In implementation using AppDomainSetup, Assembly.Load, etc..

The CLR utilizes the new System.AddIn.dll (v3.5) that will ship with Orcas (i.e., Visual Studio.next). This dll is a new implementation that provides Discovery (i.e., a new feature), AppDomain creation (including a simplified enum for Full Trust, Intranet, and Internet), Assembly loading, and Add-In activation.

The CLR and VSTA loader implementations also provide AppDomain (AD) creation (and pooling) as well as out of process creation (and pooling of AD’s therein).

System.AddIn.Contract.dll remains basically the same (after all it cannot change in a breaking way).

The generic vs. custom contract model is the primary difference in the two (i.e., CLR and VSTA) implementations. VSTA provides the implementation of the generic contracts and the CLR now provides the base implementation of IContract, as well as other infrastructure that previously resided in VSTA.

The overriding design goal of VSTA was to provide a next generation managed solution akin to VBA. As a result, we needed to support existing VBA partners in the most transparent way possible. To this end, we created a tool called ProxyGen that takes as input, either a COM object model (using TypeLibs) or an existing managed object model (using reflection) and produces as output, a proxy dll that Add-In’s program against. You can think of the tool as a similar to tlbimp. The proxy also has some code that handles “remote reflection”. In addition to the proxy (Gen), VSTA shipped two Adapters: A COM adapter which used IJW to call from Managed code through IDispatch to an existing COM OM. And a managed Adapter that does local (on the Host side) reflection on a managed Host object model. The adapters do not change as the Host object model (OM) changes. The proxy may change for new Add-In’s to take advantage of new host functionality. As a result of this dynamic “pseudo” late-bound model, VSTA utilized a set of “generic” (i.e., predefined for VSTA internal usage) contracts built upon the base IContract for handling proxy requests, adaptation, remote arguments, etc…

The CLR implementation and thus customer adoption of MAF (the base) is based upon a “custom” contract model, as opposed to a generic contract model (e.g., used by VSTA). The custom contract model is more or less about expressing a type as a contract and it is built upon what we call a pipeline which handles the flow of execution between the Host Object model and the Add-In. The premise of a proxy (calling through – no implementation) is the same in both models. However the terminology and usage of terms is slightly different. VSTA exposes a proxy to Add-In’s whereas the CLR exposes a “view” to the Add-In’s, which gets adapted to a contract and adapted back again from the contract to a Host view. The CLR provides this proxy/adaptive behavior over a “pipeline” and you can read more on the pipeline model in our MSDN articles. The reality is that VSTA is using Proxies and Adapters on both sides of the boundary but since the Add-In mostly contains proxy functionality, we called the VSTA Addin side a proxy.

A picture is worth a thousand words

Diagram of the CLR model

Diagram of the VSTA Model

A few BCL additions/enhancements (I will post more on each)

· There is also the addition of BCL support for IContract collections.

· The CLR provides a base implementation of IContract, called ContractBase.

· Lifetime management.

· Discovery.

I hope this clears up some confusion or at least sparks enough questions that I can answer in an attempt to clarify some of the confusion.

Comments

• Anonymous
  August 17, 2007
  Last year, I did a webcast when I was attending an SI (Solution/System Integrator) Architect conference

• Anonymous
  January 30, 2008
  I am not quite understand the boundary in your diagram. it means the add-in and host are in the same physical process and different appdomains; or in different physical processes.

• Anonymous
  February 01, 2008
  ATS, The optional isolation boundary may be an AppDomain, or Process (and AppDomain's within).