Guest Opinion

Don't Include VB6 With VS.NET

The recent petition from a group of Microsoft MVPs notwithstanding, it would be a mistake to incorporate a version of Classic VB in a future version of Visual Studio.

A group of Microsoft MVPs has recently surfaced a petition to merge the VB6 IDE into Visual Studio 2007 (or whatever comes after 2005).

I, too, am a Visual Basic MVP, but I do not favor the idea of merging the VB6 IDE into Visual Studio. I just don't see this as a practical idea, for many of the reasons Paul Vick lists in a recent blog. The fact of the matter is, the only real factor in how long VB6 continues to be used will be how long businesses continue to find VB6 financially viable.

The issue itself appears to be spinning out of control, not least because various media outlets are jumping in. The blogsphere and numerous trade publications have gone berserk over the subject, writing both pros and cons. (Editor's note: VSM itself ran an editorial by Karl E. Peterson wherein he explained why he sponsored/supported the petition "Support Classic VB," [May 2005]).

I've been in this industry for nearly 20 years. My first job was porting code from PDP-11 to VAX. But there were still companies running that PDP-11 software 10 years after the hardware was no longer manufactured.

The lesson? Companies run old, dead technology.

They do so because it works. Companies are nothing if not pragmatic, and that's OK. But none of those companies expected DEC to support the long-dead PDP. They built their own support network through user groups and a sub-industry of recyclers who sold refurbished parts for many years after nothing new was made.

VB6 is the PDP-11 of today. Support is ending, though technically Microsoft has support options through 2008.

And you know what? Companies will continue to run VB6.

Again, because it works. Microsoft would prefer that you upgrade, but you don't have to. And that's OK. However, like the people running the PDP-11s, you can't expect Microsoft to support a dead tool. This is especially true because Microsoft has provided a far superior alternative to the discontinued tool in the form of VB 2005.

It's cool with me if you want to keep using VB6. More power to you, even. That said, you do need to accept the costs of handling your own support if you choose to do so—as does anyone who chooses to continue using dead technology.

I'd be willing to bet a decent sum of money that none of those old companies I mentioned previously continue to run PDP-11 today. The reason: The cost of using a dead technology eventually outweighs the cost of moving forward. Businesses that depend on such technologies eventually must face the fact that there comes a time when it is more expensive to continue relying on a dead technology rather than adopt a newer, more productive, technology.

This analysis will eventually hold for VB6, as well. It is simply a cost/benefit decision at a business level, nothing more. For some time to come, it will be cost-effective to maintain VB6 code, even though the technology is dead. Eventually—whether it is five, 10, or 20 years down the road—the cost differential will make it far more effective to move to a more modern and supported technology.

I doubt that many developers would choose to continue to use VB6, apart from a few odd ducks. Certainly, few developers would choose to continue using VB6 after using the more recent versions of VB.NET or VB 2005 for a few days. I've seen countless people make the migration, and none of them are pining for the "good ol' days of VB6" after using VB.NET. Mostly, this is because VB.NET is just so damn much fun!

Press the VB6-focused MVPs, and you'll find that they stay with VB6 for business reasons, not technical ones. Their customer bases are pragmatic, conservative, and remain at the point where the cost of running a dead technology is less than switching to a more modern technology. And that's OK. That's business.

What irritates me is when people let emotion into the discussion. This shouldn't be a dogmatic discussion.

It is business, pure and simple.

The opinions expressed in this editorial are those of the author and not necessarily the opinions of VSM. This editorial was adapted from a blog posting by Rockford Lhotka at

About the Author

Rockford Lhotka is the author of several books, including the Expert VB and C# 2005 Business Objects books and related CSLA .NET framework. He is a Microsoft Regional Director, MVP and INETA speaker. Rockford is the Principal Technology Evangelist for Magenic, a Microsoft Gold Certified Partner.

comments powered by Disqus


  • What's Next for ASP.NET Core and Blazor

    Since its inception as an intriguing experiment in leveraging WebAssembly to enable dynamic web development with C#, Blazor has evolved into a mature, fully featured framework. Integral to the ASP.NET Core ecosystem, Blazor offers developers a unique combination of server-side rendering and rich client-side interactivity.

  • Nearest Centroid Classification for Numeric Data Using C#

    Here's a complete end-to-end demo of what Dr. James McCaffrey of Microsoft Research says is arguably the simplest possible classification technique.

  • .NET MAUI in VS Code Goes GA

    Visual Studio Code's .NET MAUI workload, which evolves the former Xamarin.Forms mobile-centric framework by adding support for creating desktop applications, has reached general availability.

  • Visual Studio Devs Quick to Sound Off on Automatic Updates: 'Please No'

    A five-year-old Visual Studio feature request for automatic IDE updates is finally getting enacted by Microsoft amid a lot of initial developer pushback, seemingly misplaced.

  • First Official OpenAI Library for .NET Goes Beta

    Although it seems Microsoft and OpenAI have been deeply intertwined partners for a long time, they are only now getting around to releasing an official OpenAI library for .NET developers, joining existing community libraries.

Subscribe on YouTube