| August 2006 |
| Making the Move from VB6 to VB.NET |
| By Matthew D. Sarrel |
|
|
| With Microsoft eliminating free support for Visual Basic (VB) 6, it may finally be time for VB6 developers to learn VB.NET. Launched approximately five years ago, VB.NET provides an object oriented programming methodology that VB6 lacks. Many developers have been reluctant to learn VB.NET because it is like learning a new language, but such reluctance is akin to an ostrich hiding its head in the sand. Object oriented programming is the way to go, and over the next few years there will be a great deal of migration of enterprise applications from VB 6 to VB.NET. Even with migration wizards, the process is not transparent; developers need to know the differences between the languages in order to migrate successfully. The Big Picture If you haven’t developed for .NET yet, we should probably start with some information about what it is and what its benefits are. Most important to VB6 programmers, .NET replaces the Component Object Model (COM) which allows separately compiled programs written in one or more programming languages to work together. .NET is also an object oriented class library which replaces Microsoft Foundation Classes (MFC). The .NET Framework is essentially a huge collection of code and runtime tools for developing seemingly language-independent Windows and Web applications. There’s even a .NET Compact Framework for handheld devices. Previously, if you wanted to create an application from code written in two or more programming languages, then you would have needed to use COM. Many VB programmers do this on a daily basis without realizing because the controls installed in their VB6 toolbox may have been written in another language such as C++. Yet, when they drop those controls onto a form, COM allows them to be used as if they had been written in VB. Using COM, separately compiled files (DLLs) and controls (OCX files) communicate with each other using predefined interfaces. All COM objects function according to a specific set of rules which dictate the entrance and exit points through which compiled files communicate. There are a few disadvantages to this model. Programming COM objects can be error prone. The biggest disadvantage is that each COM component has to be registered in the Windows Registry. Unfortunately, it is too easy (and common) to register multiple incompatible versions of the same component which causes hard to trace errors. The .NET framework offers a much cleaner alternative to COM. Each application is made up of multiple files which, in addition to the executable, may also contain controls, DLLs and graphics. These are grouped together as an assembly, and all files grouped together in the same assembly share a common version number. This means that applications can use their own separately compiled files without relying on the Windows Registry. When multiple applications rely on the same compiled file, the file is placed into a shared directory. References to shared files can be maintained in an XML (eXtensible Markup Language) configuration or config file which is stored in the application directory. If the application uses a specific version of an installed component, then that version can be specified in the application’s config file. This eliminates many of the incompatibilities common in COM; applications in .NET do no accidentally use incompatible versions of controls because of a mistake hidden deep within the bowels of the Windows Registry. In contrast to VB6, VB.NET has the important advantage of integrating easily with code written in other languages. All .NET languages share the same class library and runtime environment, so it is possible to create a project with some modules written in VB.NET and others written in C# or J#. It’s simply a matter of importing the C# or J# code into the VB.NET code and then creating VB.NET objects based on those classes. Once that’s done, it’s possible to use the methods of these classes as if they had been written originally in VB.NET. Another improvement that can make developers more productive is the ability to develop, debug and share drag-and-drop controls. Using a Visual Studio .NET wizard, controls can be designed and coded as if they were part of a standalone application. These controls can then be installed into the Visual Studio Toolbox. Properties can be set using the “property” keyword, and when the control is dropped onto a form in the Visual Studio .NET workspace these properties will automatically appear in the control’s properties list. The Nitty Gritty The biggest difference between the two versions is that VB.NET is an Object Oriented Programming (OOP) language. In VB6, objects were not essential, but code could be written to create one. With VB.NET, objects are fundamental, so much so that VB.NET can almost be thought of as a separate language, rather than simply a new version, of VB6. In VB6 it was not possible to create family trees of objects where descendents inherited the features of their ancestors. This functionality has been added to VB.NET so that it is better suited for comparison to C# and Java than to VB6. VB.NET also benefits from the superior exception handling typical of an OOP language. Exceptions are returned as objects which can be examined to determine the exact nature of the error. In addition, each exception has its own string “Message” property which can be used to display information about the error. A block of code that could produce an exception can be enclosed between the “try” and “catch” keywords. If an exception occurs after the “try” statement, the code following the “catch” executes. It’s possible to have multiple “catch” clauses to handle different specific errors. An optional “finally” clause can be added to perform needed cleanup regardless of whether or not an exception occurs. This automated process is much more sophisticated than error handling in VB6, although you can still use the old “on error goto” statements if you hold them near and dear to your heart. While there is an upgrade wizard, migrating your old VB6 projects into VB.NET will almost certainly require manual coding. The upgrade wizard is a valuable tool, but it can only convert simple projects without error. A more typical experience is that the wizard will encounter lines of code that cannot be automatically converted and will mark these lines with comments containing hyperlinks to additional help information. In many cases, code will need to be substantially rewritten. For example, a database application that uses ActiveX Data Objects (ADO) will need to be recoded to ADO.NET. There is a ton of information about moving from VB6 to VB.NET on the web at sites like TechTarget, MSDN, O’Reilly, and more. While migration will not be a straightforward process for your code, with some education and preparation it can be a straightforward move for you. Matt Sarrel is executive director of Sarrel Group and a technology journalist based in New York City.
Comments? Please contact us at feedback@dice.com.
|
|
||||||||||
|
||||||||||
|
||||||||||
