As I’m sure most of you know, the future of VBA and VB.NET for Office Developers is still undecided. The Visual Studio Tools for Office has introduced Office to those that have adopted .NET, but has done nothing to introduce .NET to the traditional Office/VBA developer. VSTO has also unearthed some fundamental issues that effectively prevent us from controlling Excel from .NET reliably, which have yet to be fixed. I’m sure you’re also aware of the amazing synergy between VBA and Visual Basic 6 (aka ‘Classic VB’); many VB6 code snippets can be dropped into a VBA project and used without any changes, and it’s extremely easy to move VBA code into VB6 DLLs for better performance, improved security and better handling of class modules. Looking back, we can readily see that VBA has tended to follow in VB’s footsteps and it’s not difficult to predict that the same will continue into the future.
And that gives us all a very big problem.
When Microsoft introduced .NET, development of Classic VB stopped and the product entered the support phase of its lifecycle. Development of VBA stopped at the same time; Office 2000, XP and 2003 all have exactly the same VBA IDE. Right now, we’re all developing Office-based applications using a language and development environment that hasn’t changed in five years, and will probably never be updated. What is likely to happen is that VBA (and the VBA IDE) will continue to exist in its current state and Microsoft will introduce a new way for us to use .NET to program Office – perhaps using the Visual Studio.NET IDE, perhaps creating a brand new IDE just for Office. What is critical to us all is how that is done, such that we will be able to adopt .NET and use it alongside and integrated with the millions of lines of working VBA code we already have. If VBA follows the VB6 experience, we have a bleak future.
It’s almost unanimously agreed that Microsoft got it wrong when introducing VB.NET, by not providing an easy route for all the existing VB6 developers to start to include VB.NET into their applications. Microsoft effectively gave them an “all or nothing” choice – keep working in VB6 or rewrite your application in VB.NET. (Sure, they made an attempt at a code converter and provided the ability to interop between VB6 and VB.NET dlls, but both those options could only be used by a small fraction of VB6 developers).
What you might not know is that mainstream support for Visual Basic 6 ends on March 31. To mark this event, lots of MVPs past and present have put together a petition urging Microsoft to reconsider their past mistake and reintroduce ‘Classic VB’ as a mainstream language incorporated into Visual Studio, alongside VB.NET. They point out that (unmanaged) C++ coexists happily with (managed) C# and that by supporting both (unmanaged) Classic VB and (managed) VB.NET, Microsoft would finally be preserving all the investment their customers have made in their VB6 applications, provide an up to date language and IDE for maintaining those assets going forward and (perhaps most importantly) provide a platform for the gradual and managed migration of that VB6 code to VB.NET, where (and if) that makes sense.
If Classic VB is included in the Visual Studio IDE, it would be a very small step to also support VBA and thereby provide a clear path for us all to tread, allowing us to decide when, if and how to include .NET code in our Office-based applications. Microsoft already knows that an extremely high level of VBA/VB.NET interoperability is a ‘must have’ if they want their VBA customers to adopt .NET; the MVPs’ petition suggests a way in which that can be accomplished.
The Coca-Cola company corrected their big mistake by reintroducing ‘Classic Coke’. Please sign the petition to ask Microsoft to do the same, and give ‘Classic VB’, VBA and all our existing code a future.