We saw in the earlier posts how simple it is to enable an application to load add-ins and enjoy all the benefits that come with loosely coupled usage of the host object model.  CLR Add-In framework is the base for implementation of VSTA 2.0. Refer to blogs.msdn.com/clraddins for details around the Add-In framework.  To keep it simple and straightforward lets dive into the details of the integration code that was provided in the earlier post so that we could understand the workings of VSTA in a better way. The integration code below starts with defining a class Program with a Main method. It defines two instance variables

serviceProvider: As VSTA is based on CLR Add-In framework, this brings up the fact that VSTA is based on a single generic System.AddIn based pipeline. Once the pipeline is activated by standard CLR Add-In activation methods we need a mechanism for the host to hook into this pipeline. One way VSTA pipeline provides these hooks is through its entry point interface (IEntryPoint and IExtendedEntryPoint). This interface at its core is just a view (in terms of CLR Add-Ins terminology) that is used to get handle to the activated add-in. Once this interface is obtained from the initial activation of the add-in Initialize method provides a mechanism of registration of an IServiceProvider implementation from the host.  This service provider is basically responsible for providing two main services TypeMapProvider service and HostItemProvider service. We will look at the role of these services in a while. serviceProvider instance object holds a reference to the service provider.

vstaPipelinePath:This is the relative path under the commonfiles folder where the VSTA pipeline is laid as part of the install. This is under

C:\Program Files\Common Files on x86 machines and

C:\Program Files (x86)\Common Files on x64 machines. 

Hence the absolutePath of the pipeline is as computed in the code below

string commonPath = System.Environment.GetFolderPath(System.Environment.SpecialFolder.CommonProgramFiles);

string pipelinePath = System.IO.Path.Combine(commonPath, vstaPipelinePath);

//C:\Program Files\Common Files\ Microsoft Shared\VSTA\Pipeline

Once we have the pipeline path with us, we could activate the add-in using AddInStore (System.AddIn.dll) type passing the view and the pipeline path as two of the parameters. Other two parameters are Add-In path and namespace qualified name of the add-in entry point class.

Post activation we need to provide our implementation of service provider. The instance is created in the method below InstantiateServiceProvider. As discussed above the creation of the instance provides specifying two service’s HostItemProvider service and HostTypeMapProvider service which should implement IHostItemProvider and ITypeMapProvider service respectively. Both of these interfaces are defined in Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0.dll.

IHostItemProvider: This interface is a means for the host to provide the host objects to the add-in. add-in initialization code would generally use this interface to get the handle to root object. You could see the entry point class implementation in the proxy class generated using proxy-gen as discussed in the earlier posts.

ITypeMapProvider: VSTA provides isolation of the add-in side types of the pipeline and the host side of the pipeline using contracts. Contracts are a restrictive boundary and only specific types can cross the contract boundary to maintain the type isolation in the CLR pipeline. (Refer to http://blogs.msdn.com/clraddins/archive/2007/02/27/restrictions-on-contracts.aspx) hence mapping between types on the add-in and the host side are maintained using unique string identifiers also referred as canonical names. ITypeMapProvider is an interface through which host can plug in string to type mappings. To facilitate host integration these mappings are generated as part of proxy code generation process via the host object model. (HostTypeMap.cs generated as part of proxy-gen)