email article printer friendly

Office and .NET: Better Together?

by Jonathan West

I'm sure glad I'm not in charge of programmability features for the next version of Office. The changes between VB6 and VB.NET will mandate choosing between three options, all of which are painful:

Jonathan West
Agree? Disagree? Tell us what you think, and see what other readers have to say.    The opinions expressed in this editorial are those of the author and not necessarily the opinions of VSM.

• Support .NET fully, dooming Office .NET to bomb in the enterprise market because today's mission-critical custom Office apps won't port to .NET.
• Stick with Visual Basic for Applications (VBA) and thereby undermine Microsoft's .NET strategy.
• Make the languages group produce a VBA-compatible language on the .NET platform, crossing those Microsofties who'd decided the syntax changes in VB.NET were a cool idea.

Underlying this mess is VBA's success. Tremendous synergy followed its incorporation into Office, starting in Office 95 and completed in Office 97. VB and Office programmers could move between applications with relative ease, reusing lots of general-purpose VB/VBA code. As a result, many companies now have large, custom VB/VBA Office applications, often performing mission-critical tasks. These companies must be sure their custom applications still will run before they dare roll out a new version of Office.

Microsoft currently offers Visual Studio for Applications (VSA) as a way to add VB.NET scripting capability to applications. This is supposed to provide a replacement for VBA in third-party apps, especially when Web-enabled. Microsoft is licensing VSA to other companies, so it's reasonable to assume the company plans to incorporate VSA into Office in due course.

We know you face massive rewrites using the VB6 to VB.NET migration wizard, and I've seen nothing to make me think you'll be able to avoid this in a VBA migration. As a result, companies will ask themselves why they should pay Microsoft for the privilege of being forced to rewrite their Office VBA apps. The companies will look at their financial interests, and many (maybe most) will decide to pass on the upgrade this time.

If VB.NET proves unpopular, Microsoft takes a minor hit. But Office produces one of Microsoft's top two revenue streams. If it bombs, that would be a career-truncating event for the designated scapegoat.

Of course, that executive could avoid this scenario by deciding that VSA isn't suited to Office, and that Office sales matter more than moving Office to .NET. But this would undermine Microsoft's .NET strategy, because if .NET isn't good enough for Office, how can Microsoft plausibly claim it's good enough for the rest of us? In addition, the company would lose the synergy with VB.NET that VB6 had with VBA. Whichever way you look at it, this isn't a career-enhancing move either.

As the Microsoft executive in the hot seat, you could leave VBA in Office alongside VSA, but that raises other issues. Do you extend the VBA object model or restrict new features to VSA? If Microsoft doesn't extend VBA, then why should companies upgrade to the new version of Office from a programmability standpoint? They won't be able to extend their existing VBA apps with new Office features. But if Microsoft does extend VBA, customers will have no reason to move their existing apps to VSA, and Microsoft gets a double load of development and support costs and thoroughly confuses the market regarding its strategic direction.

I favor making a VBA-compatible language available on the .NET platform as the key component of VSA for Office. I'd license it to third parties as well as sell it as a standalone language. That way, customers could upgrade existing custom VBA apps easily, Microsoft would retain the synergy between VB and Office programming, and everyone could still reuse their old code samples. As a bonus, they'd also get a better upgrade path for VB6.

However, taking this tack casts doubt on the wisdom of taking VB.NET so far from VB6. It would require top-level support within Microsoft to push this option through, because it would thwart the VB.NET evangelists by crossing the people who'd made those decisions. But the need to save Office might produce the needed support within Microsoft.

VB and VBA have become too important to Microsoft to be thought of as just a development tool. The future of Office—perhaps even the company—is riding on the decision about the future of VBA in Office. I don't envy the person who'll have to make it.

About the Author
Jonathan West is an independent consultant specializing in Office VBA solutions, technical documentation, and technical standards writing for the telecom industry. He's been a Microsoft MVP since 1997. Contact him at .