Integration Styles and the Benefits: SDK, NoRuntime, and ProxyShim

For VSTA integrations, there are a variety of ways in which the host can load and interact with add-ins.  Three styles of interest are SDK, NoRuntime, and ProxyShim.  Each style of integration has many pros and cons to consider before deciding on which type is best for a particular host.

SDK style: 

This is the style of integration which uses the VSTA runtime and pipeline to load and execute add-ins which reference the host only through a proxy.  Add-Ins use an IEntryPoint or IMultipleEntryPoint interface.

Pros:  This style of integration offers all of the benefits of the VSTA runtime such as the security and isolation options of loading add-ins into separate app domains, add-in discovery and loading through the VSTA pipeline, as well as trust level options for loading add-ins.  The use of a proxy allows the benefits of versioning and use of an Object Model which allows for hiding public items in the host application.  Add-ins refer to the host through “this.” or “.me” calls.  An EventHelper can be used which prevents exceptions thrown in add-ins from affecting the host application.  Dynamic Programming Model add-ins are possible with this style of integration.  VSTA v 1 SDK style add-ins can be upgraded to VSTA v 2 SDK style add-ins.

Cons:  A full proxy is required for SDK style integrations.  Use of a full proxy eliminates support for generics and the new operator.  As well, structs and custom exceptions must be redefined in the proxy, and nested classes require manual changes to the proxy.  There is a memory usage bug which causes memory not be released once an add-in is unloaded.  During debugging, objects on the host side cannot be viewed in windows such as locals and immediate, instead they show up as a transparent proxy with no valid data in the properties.  The loading and execution of add-ins is slowed by traversing proxy layer.

NoRuntime:

In a NoRuntime style integration neither the host nor add-ins reference the VSTA runtime.  Instead the add-ins reference the host directly and do not use a proxy.  Add-ins are loaded through Assembly.Load calls instead of through the VSTA pipeline.  Add-ins use the IAddIn interface instead of IEntryPoint or IMultipleEntryPoint.

Pros:  This style of integration uses a direct reference to the host application; therefore, generics and the new operator are supported.  Structs and custom exceptions do not need to be redefined in a proxy layer.  As well, nested types are support with no code changes or effort.  During debugging there are no issues with viewing host objects in windows like locals and immediate.  Add-ins are loaded and executed quickly because they are not slowed by a proxy layer.  The memory usage footprint for unloaded add-ins is less than in SDK style integrations.

Cons:  NoRuntime style add-ins require a code file in each add-in to be used in place of the auto-generated designer file (this file can be hidden).  The runtime benefits for security, isolation, and versioning are lost.  Add-ins must be loaded in the same app domain as the host.  It is not possible to hide public items in the host because the add-ins use a direct reference instead of an Object Model defined in a proxy layer.  Exceptions thrown in add-ins can affect the host application.  Add-ins cannot refer to the host through “this.” or “.me” calls, instead a “this.app” or “me.app” style call must be used with a local variable.  It is not possible to use the Dynamic Programming Model with this style of integration.  VSTA v 1 SDK style add-ins cannot be upgraded to VSTA v 2 NoRuntime style add-ins; however, they can be upgraded to ProxyShim style add-ins and loaded in the same manner (with the same code) as NoRuntime style integration add-ins.

ProxyShim:

The ProxyShim style integration is a hybrid between the SDK style and NoRuntime style integrations.  Both the host and add-ins reference the VSTA runtime, but add-ins are loaded through Assembly.Load calls instead using the VSTA runtime or pipeline.  ProxyShim style add-ins use both the IAddIn and IEntryPoint or IMultipleEntryPoint interfaces.  These interfaces are defined in an additional code file in the add-in and in a very small proxy which contains definitions only for entry point types.

Pros:  Like NoRuntime style add-ins, ProxyShim style add-ins use a direct reference to the host application and can therefore support generics and the new operator.  Neither structs nor custom exceptions need to be redefined in a proxy layer.  As well, nested types are supported with few to no code changes depending on their involvement with entry point types.  During debugging there are no issues with viewing host objects in windows like locals and immediate.  Add-ins are loaded and executed quickly because they traverse only a minimal proxy layer.  The memory usage footprint for unloaded add-ins is less than in SDK style integrations.  Add-ins reference the host through “.this” or “.me” calls.  VSTA v 1 SDK style add-ins can be upgraded to VSTA v 2 ProxyShim style add-ins through an upgrade helper.  It is possible to support Dynamic Programming Model add-ins with this style of integration and with an improvement over the SDK style DPM (for more information on this please see the blog Referencing Host Items in a DPM Project from the Host Item Container).  ProxyShim add-ins can be loaded in the same manner as NoRuntime add-ins; therefore, both types of add-ins can be used by the same host with a single LoadAddIn method.

Cons:  Like NoRuntime style add-ins, each add-ins requires a code file to be used in place of the auto-generated designer file.  The runtime benefits for security, isolation, and versioning are lost.  Add-ins must be loaded in the same app domain as the host.  Except for the entry point type, it is not possible to hide public items in the host because the add-ins use a direct reference instead of an Object Model defined in a proxy layer (the proxy used in ProxyShim style integrations defines only entry point types).  Exceptions thrown in add-ins can affect the host application.