Despite the hurdles facing VB developers who are moving to the .NET platform, it’s not only a possible transition, but a worthy one as well. Learn more about how to approach this migration to achieve the best results.

Though many organizations are still in the investigation stage regarding a full-fledged transition to .NET, Visual Basic 6.0 developers are feeling the heat. They know their skills need to be updated, and they’ve read enough to know that the transition is not going to be easy.

Development organizations are carefully considering this transition as well. How can Visual Basic 6.0 teams be converted in the context of shrinking consulting and training budgets? They’ve read the warnings: “Despite Microsoft’s wizards and tools, it will be a major challenge for coders used to writing simpler—and less powerful—procedural code” (Frank E. Gillett, Forester Research, Feb. 13, 2002). Managers are struggling to decide how to implement this transition in 2003 with limited resources and without tossing out their aggressive development schedules.

It would help to know the hurdles a Visual Basic 6.0 developer faces in the course of this transition. Various commentators have vaguely referred to the requirement to move to a pure object-oriented (OO) environment as the highest hurdle but usually nothing specific is mentioned. After interviewing several developers that have made the move from Visual Basic 6.0 to C# or Visual Basic .NET, I have put together some specific issues that describe the challenge of transition.

Visual Basic 6.0 is a hybrid language. It has evolved from its procedural roots into something like an OO language. Object purists were never happy with the various changes that were added to support OO, but large numbers of developers and development shops found it to be an effective compromise between rapid application development (RAD) and OO. In the process a sizable number of developers “grew up” with this quirky mix of features. These quirks now represent some of the hurdles to transition.

C# and Visual Basic .NET are pure OO languages, and though Microsoft does support various backward-compatible mechanisms (including On Error Goto and WithEvents) with Visual Basic .NET, developers who made the transition to .NET likened it to “swimming in Jell-O” during their first development project.

The runtime library
One obvious factor was the sheer size of the runtime library. The base class library has over 4,500 classes with a vast array of methods and properties. Even after attending training and/or reading good books, developers indicated that working the simplest of tasks was, in fact, more like completing research projects. Incomplete help systems and inaccurate third-party books further hindered those making this transition in the beta timeframe. Nonetheless, knowledge of the expansive runtime library provided in .NET is crucial to have if the continued competitive RAD results are expected of the new iteration of Visual Basic.

Understanding references
For some Visual Basic 6.0 developers, the indirection provided by references is confusing. Though Visual Basic .NET does not support C-style pointers and C# supports them only in “unsafe code,” the concept of separation between an object and its references needs to be clearly understood. Visual Basic 6.0 developers who are experienced with writing classes and managing collections have this down, but there is a segment of programmers that are still vague about the difference between passing an object by reference or by value and what exactly it means when an object is set to Nothing or when one object variable is set to equal another.

Understanding aggregation options
For developers that have programmed solely in Visual Basic 6.0, data structure experience likely has been quite limited. Before .NET, Visual Basic was sadly underprovided with aggregation options, and most developers are familiar with only three data structures: arrays, Collections, and Recordsets. The wide array of data structures in .NET can be quite daunting, with such items as Queues, Stacks, Hashtables, and ArrayLists. For instance, uninitiated developers must ask themselves when do they throw objects directly into a SortedList and when do they build their own data set by inheriting from CollectionBase. Once it becomes clear how much power and flexibility is provided by these objects, base classes, and interfaces, Visual Basic developers begin to realize what they’ve been missing!

Understanding events
The event mechanism in Visual Basic 6.0 is quite quirky and inflexible requiring explicit object declaration using the WithEvents keyword and particular naming syntax. Furthermore, Visual Basic style events were not scalable in distributed environments, nor even reliable. Most Visual Basic 6.0 developers steered clear of writing any custom outbound interfaces and did not think about the magic required to send execution to a cmdOK_Click subroutine.

Though in Visual Basic .NET the WithEvents mechanism is still supported, .NET introduces a new event model, which is much more flexible and provides significantly better performance. This new model is right in your face the first time you double-click on a button to write the handler, but it feels so much like the Visual Basic 6.0 model that developers may not realize the power and flexibility available. For example, developers interviewed didn’t necessarily realize that a centralized handler could be used for any number of signature-compatible user-interface events. In the user-interface, developers were still writing one handler per event per control and missing out on a significant reuse opportunity. The concept of delegates often still remained a mystery and the value-proposition of custom-built, loosely coupled events or the publish/subscribe pattern was not clear.

Understanding inheritance
Perhaps the most discussed transition is the ability to use true implementation inheritance. .NET did not just add inheritance as a feature to Visual Basic, .NET made it a primary characteristic. I’ve both heard and read opinions that Visual Basic developers can still function without really understanding inheritance. That is ridiculous. You cannot even navigate the help system without a good grasp of inheritance. I would not want developers working on my project who could not create a type-safe collection using CollectionBase.

It is true that a .NET developer can be effective without understanding object-oriented analysis and design (OOAD). .NET developers must understand OO mechanisms (inheritance, constructors, method overloading, and so on) but do not necessarily need to be trained to design effective business object models. UML is not a required .NET skill. Of course, it would be useful to have an OOAD understanding, but the minimum requirement is a solid grasp of the mechanics of OO and its application as a language mechanism.

Once again, Visual Basic 6.0 is a barrier to this understanding. Interface inheritance in Visual Basic 6.0 is a mess. Not only was a developer required to nest objects or create some other workaround to simulate implementation inheritance, but also there was no way to access more than one interface through a reference variable. If a class implemented three interfaces, the developer would declare up to four reference variables to access all of its methods and properties. Implementing an interface hierarchy was extremely cumbersome. Most Visual Basic 6.0 developers who attempted using interface inheritance rightly rejected it as not providing enough benefit for the cost of complexity.

Visual Basic 6.0 developers need to shed the memory of that nightmare. Inheritance in .NET is straightforward and natural. The benefits far outweigh the complexity costs.

Transition planning
In designing a transition plan for yourself or for a team of Visual Basic 6.0 developers, be sure that it addresses each of these areas:

  • A survey of the runtime library, with samples for elements relevant to the target application
  • Clear instruction on the role of references
  • An introduction to .NET aggregation options
  • A description of the value-proposition of events and delegates
  • A considerable amount of time set aside for understanding OO language mechanisms, like inheritance, constructors, method overloading, and class-level variables