Running VSTA without the proxy

The MS VSTA team has provided 2 examples of running VSTA without the proxy.  Both cases simply and directly connect the add-in to the host application.  Summit devs looked at these examples and offer this guidance:

==

The first example is the script task in SQL Server Integration Services (SSIS) Business Intelligence Developer Studio. 

After installing SSIS (we installed it on a clean machine), here’s how to open VSTA:

1)       Start -> MS SQL Server 2008 -> SQL Server Business Intelligence Developer Studio.

2)      From the Developer Studio, File | New Project…  Select ‘Integration Services Project’

3)      From Control Flow Toolbar, Drag ‘Script Task’ control flow item onto Control Flow design surface.

4)      Right click on the newly added ‘Script Task’, and select ‘Edit Script…’

5)      VSTA IDE will come to front. 

6)      Show All, open References

7)      From VSTA IDE Build,  Run, select ‘Start Debugging’

8)      From VSTA IDE select ‘Stop Debugging’

Observe that the VSTA project (and resulting add-in) holds no reference to Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0.  This VSTA add-in is a normal .NET class library assembly holding a reference to its host application OM.  We assume that it is directly loaded by the Business Intelligence Developer Studio process and that the add-in cannot be unloaded from Business Intelligence Developer Studio process without unloading Business Intelligence Developer Studio.

Design Time:

SSIS’s Business Intelligence Developer Studio, VSTA Design time experience (Destructive Debugging):

To debug an add-in using VSTA IDE, ‘Start Debugging’ launches a new instance of the host application which loads the add-in assembly, then ‘Stop Debugging’ destroys that instance of the host application.  Each edit-compile-debug cycle of the design process launches and destroys a new instance of the host application.  This destruction allows the add-in instance to be unloaded along with the host process.

Runtime:

When the completed VSTA add-in is loaded as a script task for runtime use, it remains loaded in its host process until the host process is unloaded.

==

The second example is illustrated with a modified SDK sample: 

ShapeAppMacroRecordingCSharp-NoRuntime.

Like VSTA add-ins in SSIS’s Business Intelligence Developer Studio, this sample runs VSTA add-ins without a proxy/VSTA runtime.

Steps to use ShapeAppMacroRecordingCSharp-NoRuntime:

1)      Delete the %MyDocs%\ShapeAppCSharp folder on test machine.

2)      Extract and build the sample as ShapeAppMacroRecordingCSharp per SDK instructions.

3)      Run the included set up file

4)      Run the sample directly from the exe (ShapeAppMacroRecordingCSharp\integration\MacroRecording\bin\Debug\ ShapeAppCSharp.exe, or by selecting Debug\Start Without Debugging-  do not debug from Visual Studio (

5)      Launch the IDE

6)      Resolve the reference for ShapeAppCSharp by adding the reference- select browse and use the exe from this sample

7)      Record a macro of dragging a shape onto the active drawing

8)      Add a break point to the macro

9)      Clear the active drawing

10)   Place the IDE in debug mode

11)   ’Tools | Run Macro’ to run  the macro from the ShapeApp Macro Manager dialog

12)   ‘Stop Debugging’  in the IDE

13)   Edit the macro and build (ie:  change which shape is added)

14)   Run the updated macro.

15)   Close the host

Observe that the VSTA project (and resulting add-in) holds no reference to Microsoft.VisualStudio.Tools.Applications.Runtime.v9.0 or to a proxy OM.  This VSTA add-in is a normal .NET class library assembly holding a reference directly to its host application OM.  It is also directly loaded by the ShapeApp host application (see below).  The macro add-in is discarded, but cannot be unloaded from the ShapeApp application without unloading the ShapeApp host application.

Design Time:

‘ShapeAppMacroRecordingCSharp-NoRuntime’ Design time experience (Non-Destructive Debugging):

To debug an add-in using VSTA IDE, ‘Start Debugging’ the existing host application directly loads and executes  the add-in assembly:

 Assembly.Load(assemStream, pdbStream)

IAddIn addIn = (IAddIn)(System.Activator.CreateInstance(t));

addIn.Startup(this.application);

‘Stop Debugging’ discards the addin instance:

this.macroAddIn = null;

The host process is preserved through the edit-compile-debug cycle of the design process.  Each edit-compile-debug cycle of the design process creates and leaks an instance of the add-in loaded for debugging.

I observed degraded debugger performance with repeated start/stop of debugger.

Runtime:

When the completed VSTA add-in is loaded as a ShapeApp macro or add-in for runtime use, it remains loaded in the ShapeApp host process until the host process is unloaded.   We observed no garbage collection of discarded add-ins.

==

Finally, another approach to supporting, generic collections and other types not supported by the VSTA proxygen (and proxygen workarounds) is via custom adapters added to the VSTA pipeline segments.   System.AddIn.Pipeline.CollectionAdapters supports passing a collection of non-serializable types.