Now that Visual Studio 2010 ...
aka "Framework 4.0"
aka "Visual Basic .NET 2010"
... is almost upon us (in an "official launch" sense - the beta's have been available for download forever), it's time to review where we are architecturally. And one thing that stands out like a Las Vegas sign (where the "Launch Event" will be held) is that VBA ...
aka the last remnant of VB6
... is still part of the architecture and - as nearly as you can tell from the official press releases - always will be. In fact, there's a brand new version of VBA that will be released as part of Office 2010: VBA 7.0! So VBA not only lives, it's still growing.
Here's the "official word" from the "The official blog of the Microsoft Excel product team":
"... we have no plans to remove VBA from future versions of Office for Windows. We understand that VBA is a critical capability for large numbers of our customers ..."
64 bit computing, also a coming thing, won't be an obstacle either. Here's another "official word" from Microsoft:
"Office 2010 also provides support for 32-bit Office 2010 applications that run on 64-bit Windows operating systems by using Windows-32-on-Windows-64 (WOW64). WOW64 is the x86 emulator that enables 32-bit Windows-based applications to run seamlessly on 64-bit Windows systems. Office 2010 lets users continue to use existing Microsoft ActiveX Controls, Component Object Model (COM) add-ins, and Visual Basic for Applications (VBA), which are primarily 32-bit because no 64-bit versions are available yet for many add-ins. Supporting 32-bit Office 2010 applications that run on 64-bit operating systems allows for better compatibility with controls, add-ins, and VBA."
And then there is VSTO - Visual Studio Tools for Office. This is ... uhhh ... was the .NET managed code alternative to VBA. Two years ago, I wrote this blog, Microsoft: Are you trying to make VSTO fail? They succeeded! ... In making VSTO fail.
My prediction is basically what has happened. "... the programming staff in the I/T department, are far more likely to simply say, 'Why not just code up this sucker in regular VB.NET? We can use any of the Office libraries we need anyway. Why complicate things with VSTO?'"
Although you can still find the term "VSTO" used a bit, Microsoft is unfriending VSTO. It used to be a separate version of Visual Studio. Now it's just an option in the install of one of the other versions. They don't even call it VSTO anymore. Now it's "Office developer tools". In fact, the official documentation for "Visual Studio 2010 Office Development" never uses the term VSTO. ... Ooooo! That's cold!
The Office gurus never used VSTO because it's Visual Studio based. VBA is convenient and accessible because it's right there inside the Office application. VSTO requires that the user 'join the programming department' by becoming a .NET programmer. The marketing judgment of Microsoft now seems to agree with my conclusion two years ago: a lot of those Office gurus are just not going to do that.
Larger organizations will force the issue by using VSTO ... uhhh, excuse me ... "Office developer tools", Sharepoint, Azure, and the other shiny new stuff under the tree to develop large systems that users will use whether they want to or not. (They'll be "too big to fail".) But even .NET is bending to the overpowering ... usefulness ... of VBA. VBA Interop will let you use document-level public methods exposed using VSTO.
Developing for one of the Office products - like Excel or Word - seems to be drifting back toward VBA, not away from it.