As I noted we also unveiled yesterday the Managed Addin Framework (MAF). MAF is necessary realization of the Addin Model architecture. It is included in two assemblies: System.Addin and System.Addin.Contract. These assemblies will ship first with the VSTA product, in the Office 12 timeframe, and then be rolled into the next version of WinFX. So MAF is an integral part of the platform.
So what is in there? There are two important pieces. System.Addin contains what we call the "Loader." The Loader is a fully trusted platform component that is necessary to activate addins and isolate them in their own domains. We solve a bunch of the AppDomain creation and isolation issues illustrated in my earlier post. I will go into great detail on the Loader in a future post.
System.Addin.Contract contains a set of "Contracts" for addin communication. We defined "contract" in our PDC talk yesterday. In COM, a COM interface was, in essence, a contract. However, .NET already has interfaces, so we needed a new, more constrained, term. We chose "contract" because the Indigo -- oops Windows Communication Foundation -- Service Oriented Architecture calls their communication interfaces "contracts". The Contract in WCF and the Contract for MAF are conceptually the same thing -- and in the future they will be exactly the same thing when WCF becomes the ubiquitous remoting infrastructure.
I will go into vastly more detail in my next post on the reasoning here, when I begin to describe the contents of System.Addin.Contract with IContract. But in brief: contracts are the types that are used to communicate between hosts and addins. A contract can *never* version. Once you publish it you can't change it -- you can always add *new* contracts, but old contracts must stay the same. This allows the pieces on either side (we call them proxies and adapters, I'll go into these later too) to version indepenedently of each other. Contracts are abstract -- no implementation. In practice they are interfaces, but interfaces with more strict rules. Contracts must define a closed system. The only types legal to expose as parameters in contracts are other contracts and primitive types like "string" and "int."
System.Addin.Contract defines a number of contracts to get you started. In fact, the contracts we supply may be all that you require. Next I will write an article on the base contract of all contracts: IContract.