VSTO was originally designed to support the building of managed extensions to Office applications. Visual Studio Tools for Applications (VSTA) was branched from VSTO with the aim of providing the same kind of support for all applications, managed or unmanaged. VSTO and VSTA are both built by the same team. Now that VSTA has been validated in a number of host applications (including InfoPath), it is now effectively a superset of the VSTO functionality. Or to put it another way, VSTO is an Office-specific subset of VSTA.
At the heart of VSTA is the Managed Add-in Framework (MAF). MAF is an architectural framework, with basic implementation in WinFx. The purpose of MAF is to support the ability to dynamically connect/disconnect host applications and add-ins that version independently, in a robust and secure way. MAF can be seen as the .NET equivalent of COM. Instead of interfaces, MAF uses the concept of contracts: like true COM interfaces, MAF contracts never version – new functionality requires new contracts. Version-resilience is achieved by the use of adapters and proxies to cross appdomains/processes, similar to the way COM proxies and stubs are used to cross apartments/processes. Because the host and add-in only depend on the contracts, they are free to version their implementation independently.
In COM, version-resilience was achieved through late-bound automation interfaces, where all parameters were coerced into VARIANTs. In MAF, a similar model applies, using runtime reflection in place of IDispatch, and using a constrained set of parameter types (simple value types, strings, enums, contracts, serializable structs). A contract is represented by the IContract interface, defined in System.Addin.Contract.dll. This is one of the pieces that is now in the WinFx platform – the VSTA guys did such a good job on the concept, design and implementation that MAF has been adopted by the core platform as the default add-in mechanism for all applications.
The VSTO v3 runtime converges back with VSTA to use MAF. There will be no impact on any user-code in VSTO solutions, because the runtime is transparent to the host. Just as with v2, v3 user-code will implement Startup and Shutdown methods, based on skeletons provided by project code-spit. The real signifcance of this convergence is that from VSTO v3 onwards we will have one single “add-in” runtime for all types of application (Office and others). Plus, of course, it means that VSTO is based on a mainstream WinFx platform technology, with all the future-proofing that implies.