Why You Need to Learn Visual Basic .NET

While classic Visual Basic is a powerful and relatively simple programming language, it has reached a "glass ceiling" in addressing the requirements of current technology. For example, classic Visual Basic provides no direct access to underlying APIs, nor does it provide inheritance—the ability to incorporate functionality from another class. Classic Visual Basic programs are also difficult to fine-tune because they are far removed from the underlying mechanics of what's going on.

In addition, classic Visual Basic works fine for developing software for the Windows platforms because Windows 95, Windows 98, Windows Me, Windows NT 4.0, and Windows 2000 all rely on the Intel x86 architecture. But today's developers simply need more horse power, for more horses.

Visual Basic .NET is an entirely new way of developing software. It will let Visual Basic programmers address the advances in hardware, communications technology, miniaturization, and the Internet, which are all converging at a breakneck pace. I for one don't want to go through again the sort of development issues encountered when PCs moved from 16-bit to 32-bit architecture and two separate executables had to be tracked and managed depending on the platform a customer was using. In the next year or so, this management nuisance will seem like good times by comparison to the array of different platforms we will have to program for. The new 64-bit Windows is right around the corner, and more and more companies are relying on the Internet to distribute information and services. These companies want to distribute information to cell phones and wireless hand-held devices. Newer smart devices and appliances are also being developed daily. These wireless devices, as well as Windows CE, which is used in Pocket PCs, all run on a non-Intel x86 CPU—and let's not forget about the Palm OS based on the Dragonball chip. The obvious problem is how can a Visual Basic developer build software and distribute it to all of these disparate devices. With classic Visual Basic, that's impossible.

Instead of having to learn new techniques to optimize programs for specific hardware and operating systems, use separate architecture-specific compilers for each new (or yet devised) platform, and then track each and every version, developers can use .NET. At the center of this new approach is the common language runtime (CLR). The CLR (which I'll describe in more detail later in this chapter) provides many benefits to Visual Basic programmers, not the least of which is the means to program in any .NET language—Visual Basic, C++, C#, or one of 17 others that target the CLR. Components written in Visual Basic .NET can be called and used by those written in COBOL .NET, for example.


	Don't get the idea that Visual Basic .NET is designed exclusively for developing applications for the Internet. To the contrary, while Internet services and code reuse are now available to us, Visual Basic .NET makes developing stand-alone Windows programs easier than ever as well. Microsoft has devoted lots of resources to ensure that you can continue to build robust and fast Windows-based applications. We don't lose our classic Visual Basic expertise. Instead we gain functionality and power.

When you program with Visual Basic .NET, most applications can be deployed with zero-impact installations; in other words, installing an application is guaranteed not to affect applications already installed on a system. One of the immediate benefits you will reap is the ability to simply use XCOPY to install your entire application. You no longer have to write complicated and error-prone registry entries. You don't have to use regedit32 to register components. And, one of my personal favorites, you don't have to contend anymore with conflicting or out-of-date DLLs. How many times have you installed a new program only to find that programs that were working now don't? Often this error was caused by an older or incompatible version of a DLL being installed over the current file by the new program. This problem alone caused countless hours of sleuthing, at least in my experience. The Microsoft .NET Framework puts an end to DLL Hell once and for all.

In most cases you simply install your Visual Basic .NET application and all the files associated with it in a directory, and you're done. At first blush, this approach might sound unbeatable, but there is more. Consider when you have to uninstall a classic Visual Basic program. The results are often unpredictable. Many times the client machine is left with orphaned files and registry entries. With Visual Basic .NET you simply delete the contents of a directory (or directory tree) and the application is completely removed from the machine. Help Desks everywhere will love this.