Use VBA in Office 2007 Applications?

Question

Is VBA going to go away any time soon, like VB6 has? Should I not develop new Office applications with VBA? Or should I be developing all new Office Apps with VSTO?

Update: Recently read this article.

Answer 1

Office VSTO offers a great deal of additional functionality over Office VBA, and while I don't believe Microsoft has signaled that it's going to terminate VBA (in fact, they've said explicitly that it will be around at least until Office 14; Office 2007 = Office 12), I think it's well worth the effort to move your applications to VSTO to take advantage of the additional flexibility and power.

I actually don't think that deprecating VBA would be feasible, since a fair amount of Office programming takes place at the macro level by business users and I don't think that's going to go away any time soon. Those folks don't generally have access to a VSTO-capable IDE.

Answer 2

Here is a comment from Microsoft regarding future VBA support. In a nutshell, it is not going away on Windows versions of Office (but is discontinued for Mac versions).

Answer 3

Microsoft has stated that VBA will be supported moving forward for the forseeable future, but they are also recommending that new apps use VSTO.

The latest Mac version of MS Office don't support VBA, and 64-bit Windows runs it in a virtual 32-bit out-of-process mode. So if you are planning a new application using Office as a platform, VSTO is definitely the way to go, but you shouldn't worry too much about legacy support.

As @cori points out, it would be a big marketing no-no for MS to just yank support and break so much existing software.

Answer 4

VBA is a long way from being depreciated, in fact VBA is to be reintroduced into the next version of Office on the MAC ( http://www.microsoft.com/presspass/press/2008/may08/05-13MacBU2008PR.mspx).

For most people on the ground, VBA and C XLLs (and VB6!!) continue to be the tools of choice. The current .NET linkages are slow and offer zero productivity gain. 3rd part tools such as ExcelDNA ease the pain somewhat but obviously the unmanaged C based (and assembler based) code base of Office doesn't sit easily with .NET.

Answer 5

VSTO has new features, but also has a number of major deficiencies compared with VBA.

For one thing, Code Access Security can make it difficult to deploy VSTO applications (that's being polite).

For another, the VSTO development environment is nowhere near as accessible to "Power User" developers as VBA. For example, no macro recorder to get you started.

And a big showstopper is that .NET interop with out-of-process COM objects doesn't work well. For example, if you want to manipulate other Office applications (Word, PowerPoint, Outlook) from within an Excel VSTO application, you will find multiple copies of these applications running in the background, for the reasons described in this KB article.

All this coupled with the huge investment in existing VBA apps means VBA won't be going away any time soon.

Answer 6

VBA add-ins are a bit troublesome to deploy, but VSTO is even more so. Also, VSTO involves a bit of overhead, as it needs to start up the CLR before running your code.

But most important of all; VSTO takes away the pain of writing VBA.

Answer 7

Microsoft have been dropping hints at a managed-code version of Office with an integrated VSTO (presumably in the same way as the VB6 IDE is integrated for VBA, so the VS IDE would be integrated for VSTO) ever since .NET was first released.

Given just how much coding is involved - and given that this would not produce any features that would be visible to users - I very much doubt that this is high on the Microsoft priority list. I can imagine that they layer a managed code set of objects over the top of the existing codebase (much as Joel Spolsky layered a set of COM objects over the existing C codebase when putting VBA into Excel in the first place) and bung a new IDE in as the default, while hiding the old one. Even that would be a major exercise (imagine writing the macro recorder!). Of course, this would make .NET a pre-req for Office, which the Office team will only accept at gunpoint.

They will never actually remove VBA from the products, of course - Excel still supports Excel 4 macros, and Word still has the WordBasic Automation object to support Word 6 macros, and there's no sign of either of those being removed, since there is too much legacy code to support - and no-one has used either of those coding models in a decade.

If Microsoft do ever put a .NET environment into Office (which, frankly, I doubt will ever happen), then they might stop adding VBA support for new Office features. That's the closest they'll get to discontinuing VBA.