Nine Compelling Reasons to Move From VBA to VSTO 2005
Like an old horse, Visual Basic for Applications has served Office developers well for many years. But there's a stronger, faster pony on the way and it's called Visual Studio Tools for Office 2005. Justin Whitney provides nine solid reasons for giving VSTO a close look, plus a special sneak peek at four new programming features that you'll find in VSTO.
by Justin Whitney
May 13, 2005
When it was first released in 2002 as part of the larger .NET initiative, Visual Basic .NET made an evolutionary leap from Visual Basic 6.0. At the same time, Active Server Pages underwent a similar seismic shift to ASP.NET, and its VBScript was replaced by VB.NET. So VB6 to VB.NET...VBScript to VB.NET... do you see a pattern?
Microsoft Office 2003 and the release of Visual Studio Tools for Office (VSTO) completed the consolidation. It gave Office application developers a way to partake of the bounty of .NET by letting them use VB.NET in the place of the familiar-but-tired Visual Basic for Applications (VBA).
With Visual Studio 2005 on the way, that means VSTO 2005 is on the way, too. Which means a sweet time for Office developers. Let's be real. As powerful as it is, VBA sometimes feels like the redheaded stepchild of VB (no offence to redheads or stepchildren - it's just an expression). But with VSTO, Office developers now have the same powerful tools and libraries at their disposal as the rest of the .NET generation.
To show you why this is a good thing, I'll cover the top nine benefits of VSTO as compared to VBA. Then, as an added bonus, I'll toss in four new features coming with VSTO 2005.
1. Managed Code Beats Unmanaged Code
While the specific architecture of a VBA app is up to the developer, typically the source is created in, and shipped with, the client document itself. This has on occasion caused some, shall we say, issues regarding security, proprietary information, and distribution of updates, to name a few.
With VSTO, business logic is compiled to a separate .NET assembly. The document in the user's hands then contains managed code extensions, which trigger the assembly's download at run time. Decoupling code from UI in this way gives both the developer and the user huge benefits that just aren't possible with VBA.
If you went through the conversion from VB6 to VB.NET then you might be familiar with many of the structural changes to the language. This was done partly so that VB.NET could share a common foundation with other languages in the Microsoft family. As the most profound change, the language was restructured to give it a more OOP flava, with all the organizational benefits that entails, such as abstract classes, inheritance, and interfaces. If you're a VB scripter who's new to object-oriented programming, then learn to "Get the Most From OOP" or learn more about "Using Abstract Classes in Visual Basic.NET".