Exclusive updates on:

Working with VBA and Visual Studio Tools for Office

by Jonathan Allen on Nov 09, 2009 |

Visual Basic for Applications is a dead-end. Though still shipped with Office and still wildly popular with power-users, development on it has long since ceased. Someday Visual Studio Tools for Applications (VSTA) is supposed to replace VBA, but it currently isn’t getting a lot of attention. Even its portal on MSDN has been pulled down, leaving only the occasionally blog post.

This leaves Visual Studio Tools for Office (VSTO) for those who want to leverage the power of .NET from within Office-based products. Rather than being embedded within a document, VSTO projects are external to Office. This allows them to be compiled into standard DLLs, deployed via OneClick or standard MSI packages, and be easily shared amongst several documents.

Most power users are not likely to want to learn compiled VB.NET or C# development. Likewise, developers are probably not going to want to rewrite all of their companies VBA resources, especially the parts currently being maintained by said power users. This means interoperability between VSTO and VBA is going to be vital for several years to come.

As Beth Massi explains, there are two ways to integrate VBA and VSTO. The easiest is to simply call the VBA macro from within VSTO by using the Application.Run method. Since the macro is specified by name, you won’t know until runtime if the macro is missing or simply mistyped.

The second method Beth Massi describes is calling VSTO code from within VBA macros. Before you can do this, the EnableVbaCallers property must be set, which will cause the VSTO code to be registered for COM interopt. Then you can use the GetManagedClass function to access the VSTO methods and properties you exposed.

You can see a complete walkthrough of both scenarios using Excel on Beth Massi’s blog.