VB Classic versus VB.NET: What’s in it for you?

VB6 has been around forever. There are hundreds of thousands of developers using VB6 (Classic), but some have made the switch to VB.NET. This global environment includes C++, C# and F# languages, as well as Microsoft Express language development environments and Visual Studio environments.

The ‘.NET’ environment requires Windows (in some cases Mac OS is supported), big resources and numerous installs of runtimes depending on the vendor’s software platform. There are some open source implementations of the framework, but that is way outside of the scope of this article.

The two smartest guys I know that can boil down the differences between VB Classic versus ‘.NET’ are Mark Markarian, founder of Automated Solutions industrial data-access software, and John Weber, founder of Software Toolbox. He deferred my requests to Win Worrall, product manager.

Mark and his crew develop communication drivers and graphics solutions for use in both environments. John and his guys resell products, and develop OPC and ‘.NET’ products for the industrial community.

At the end of the day, the application to interface with a municipal water pump house, regardless of the source product, will look and feel the same. This is for the developers, not the users.

Mark’s products support ActiveX (VB Classic) and ‘.NET’. His dispatches from the field suggest that any VB Classic application is very difficult to promote in today’s environment. I concur since I use VB Classic and have had to individually install the application due to customer requirements on hardware. It’s called DLL Hell! Mark also suggests that DLL versions can be a big pain.

The ‘.NET’ environment handles the connections between all of the required files with ease. As Mark states, the dependencies required with a VB Classic project can create a nightmare. “A managed VB.NET app can install if the ‘.NET’ framework is in place,” he said. So all of the needed support files are in the framework. Cool.

That’s user stuff. What about developer stuff?

Multi-threading is intrinsic to ‘.NET’. Project types have been expanded from simple apps, forms and ActiveX controls to a basket of types, including Windows Presentation Foundation (WPF) apps and controls, web services, and the like. You can’t export a VB classic app to the web, as such.

One of the points Mark makes, as a developer of products, is that because ‘.NET’ is type safe, fully object oriented and supports dynamic reflection, his ‘.NET’ products tend not to have any obscure runtime bugs like VB Classic can experience.

As a developer, I consider the ‘.NET’ environment a learning curve that requires some serious time. But I develop apps, not products. If 10,000 people are using your products, then it better be solid.

Win Worrall agrees with Mark on many points, including the ‘one-click’ deployment of applications and the use of the new stuff that is intrinsic in the ‘.NET’ platform like WPF.

He brings up a great point that if you develop your application using the ‘.NET’ platform and export the application to a web-based system, then it is really platform-independent, since Linux can run web servers, and you could use Google services to access it. I haven’t tried it though.

He mentions that VB Classic development isn’t even supported on Windows 7 and the runtimes (your applications) were not supposed to run, but do because of heavy resistance from the development world. Worrall wonders about Windows 8.

VB Classic isn’t being taught anymore. Hire a developer and he will probably know both, but if he or she is right out of school, chances are the ‘.NET’ card will be played.

Both companies sell and develop products for both platforms. In checking the version histories on some of the various products, it is obvious that their development focus is on ‘.NET’ and not on ActiveX, which is the component type used for VB Classic.

ComponentOne is a company that generates components, as well. They gave me their full lineup of ActiveX components to use in my apps. I wondered why at the time, but now I know. The world is moving towards ‘.NET’, and when I migrate my VB Classic apps to that platform, I will need to upgrade to their ‘.NET’ components. Cash flow!

This was a wise marketing move since, based on Mark and Win’s comments and company direction, there is nothing but ‘.NET’ moving forward. Thanks to Mark and Win for sharing.

This column originally appeared in the November/December 2011 issue of Manufacturing AUTOMATION.