VSTA: Add-ins, Macros, Debugging, and Integration Questions

Q:

I have a couple of questions that I hope you can answer:

1)  It seems that any time the VSTA documentation discusses running end-user-code, it refers to that user code as an “addin,” even if that code comes from a macro recording.  Therefore, is it fair to say that all code that end-users write or record in a host application’s VSTA implementation is ultimately run as an “addin”?   Are macros and addins really the same thing in VSTA?  Is debugging an addin really the same thing as stepping through a “macro”?    I ask because in VBA, the user can either run or step through a macro, or he can write a compiled addin, and I want to be certain I understand the model that VSTA is trying to promote. 

2) My VBA users are used to the idea of the simple VBA macro.  Therefore, I’d like to make my VSTA implementation as close to the traditional VBA experience as much as possible.  That being said, I think that an implementation that uses, as described by your documentation,

1)     “Close” integration

2)     “Non-destructive” debugging

3)     “Seamless debugging experience”

4)     Out-of-process addins

…would best approximate this. Is my thinking correct? 

A:

Here is some information that I hope answers your questions sufficiently:

Question 1: 

>>Are macros and addins really the same thing in VSTA? 

The VSTA Add-in model is, indeed, the model presently being promoted by Microsoft.  It is correct to say that all code written or recorded by the end user is ultimately run as an addin assembly.  The VB or C# code (or macro code) contained in a VSTA project is compiled into a full-fledged, .Net assembly, deployed as a .DLL, loaded, and then run with the CLR.  These assemblies are called VSTA ‘Addins’, because they use VSTA’s Managed Addin Framework (MAF) for design, debug, and run-time communication to/from the host application.  The VSTA Addin project can also be opened, built and debugged in VSTA or full Visual Studio.

>> Is debugging an addin really the same thing as stepping through a “macro”?

Debugging a macro or addin is comparable to debugging an assembly in VS with the ‘Start Action’ set to ‘Start external program’  selection.:  The typical Addin debugging session has the host application running in a separate process from the addin assembly, but there are other options:.   

There are three ways to enable add-in debugging:

1.  Visual Studio-style Debugging:  Use the VSTA debugger without modifying the host application.  This approach requires little configuration and is the simplest option  for providing addin debugging support.  To enable this kind of debugging,  set the DebugInfoExeName element of the project template file to the name of the host application executable file.  This can also be done when generating the project template using ProjectGen.

Note:  VSTA creates a new instance of the host application and runs that instance in the same process as the addin that is being debugged.  This means that the application will terminate abruptly at the end of the debugging session (in an unknown state) Terminating the application without performing clean-up tasks could lead to corrupt files and other problems.

2.  Simple Non-Destructive Debugging:  This approach gives the host application an opportunity to perform any clean up task necessary to exit properly.  To enable non-destructive debugging,  configure the host application to receive and handle notifications when the debug session starts and ends:

-       Provide values in Project Templates

Or

-       Parse command-line parameters passed into the host application (vstaHostDebugURI, vstaHostDebugReady parameters)

Then register the host application to receive Debug Notifications by passing the host debug URI value obtained from host app’s command-line parameters as a parameter to the Microsoft.VisualStudio.Tools.Applications.ExternalProcess.ExternalDebugging.RegisterExternalDebugHost(System.Uri.Microsoft.VisualStudio.Tools.Applications.ExternalProcess.IExternalDebugHost) method.

Note:  With non-destructive debugging, the application and the add-in run in separate processes.  This provides a more robust debugging environment, but cross-process communication can decrease performance.

3.  Non-Destructive Debugging with Seamless User Experience:  For a seamless debugging experience, the user need not set values in the project templates,  Instead, at runtime, use the Microsoft.VisualStudio.Tools.Applications.ExternalProcess.ExternalDebugging.RegisterExternalDebugHost(System.Uri.Microsoft.VisualStudio.Tools.Applications.ExternalProcess.IExternalDebugHost) overload that returns a unique identifier.  Add this identifier to a command-line string and pass that string to the SetDebugInfo() method of the IVstaHostAdapter instance.

>> I ask because in VBA, the user can either run or step through a macro, or he can write a compiled addin, and I want to be certain I understand the model that VSTA is trying to promote. 

In VSTA v1.0, Microsoft has promoted ‘Addin’s primarily because addin assemblies provide independent versioning, isolation and security benefits not available with VBA macros, compiled or not.  However, Microsoft’s VSTA team is aware of the value VBA developers place on the simple power of authoring macros and ‘stepping through’ or debugging them in place (without a prominent build step).  This is an important issue that they are reviewing for the next version of VSTA.

If persisting macro code is important to you, VSTA’s DTE object makes it possible to extract the macro code, allowing the host application to store the macro code separately from the compiled assembly.  If, by design, the assembly is not persisted, then it is possible for the host application to use the DTE to “re-hydrate” an empty addin project with stored macros.  In fact, it is possible for the host app to create, author, and execute addins programmatically (without user intervention). 

Question 2:  >>I’d like to make my VSTA implementation as close to the traditional VBA experience as much as possible…

1)     “Close” integration

Close integration experience would mean allowing the application’s user to open the VSTA IDE with an Addin project already open and macro code already entered based on the context of the application or the user’s selection.  Close integration would mean providing a strongly-typed object model (in proxy) so that the Addin author could always use intellisense productively.  Close integration could mean running addins in-process, but I see that you have wisely specified otherwise – running Addins in a separate AppDomain avoids security and stability problems present with Addins that run in-process with the host app (ie: VBA macros). Close integration could mean using an In-Process Host, which allows the host application to interact with the VSTA IDE and interact with an open Addin project template.    

2)     “Non-destructive” debugging

3)     “Seamless debugging experience”

“Non-Destructive Debugging with Seamless User Experience” is also called the Alt+ F11 debugging scenario by the VSTA team because it is similar to the VBA debugging experience.

4)     Out-of-process addins

VBA macros run in-process, and VSTA addins can too, but Microsoft recommends that VSTA Add-in run in a separate AppDomain from the host application.  A separate AppDomain is similar to a separate process.  Running add-ins in a separate app-domain provides process isolation, and security

>>Is my thinking correct? 

Yes!