Visual Basic .NET was released by Microsoft in 2002 as a successor to the original Visual Basic computer programming language. It was implemented on the .NET Framework 1.0. The main new feature was managed code. Programmers familiar only with Visual Basic would probably have encountered difficulties working with the new version or adapting existing programs for it.
The new platform bore little resemblance to its predecessor. While programmers expected to be able to recompile their Visual Basic source to a .NET target, the reality of the situation was that Visual Basic .NET was a vastly different paradigm.
Obvious syntax differences aside, Visual Basic .NET provides much the same functionality as C# (since they both compile down to MSIL, with the most obvious difference being the case insensitivity of Visual Basic .NET, maintaining the original case-insensitivity of Visual Basic), which is more of a problem for C# programmers trying to inter-operate with Visual Basic .NET developers than anything else.
The basic syntax remains very similar: conditions, loops, procedures, sub-routines are declared and written in the same manner (see Visual Basic). Mobility from prior Visual Basic iterations to Visual Basic .NET really are parts of existing code: programmers with experience in both worlds are required to effectively target the new platform with older logic. The Visual Basic .NET developer will have to learn the use of the basic .NET types rather than what they have been used to in Visual Basic.
A programmer who has only worked with Visual Basic may encounter a steep learning curve to migrate to Visual Basic .NET. A programmer who is versed in another language or who has had exposure to the .NET runtime should be able to cope. It would be better to think of Visual Basic .NET as a new language inspired by the classic Visual Basic rather than as a continuation of Visual Basic 6.0, with the added difficulty for migrating programmers that VB.NET interfaces with the .NET Framework whereas VB6 was based on the Component Object Model (COM).
There are some immediate changes that developers should take note of:
Visual Basic .NET allows for the +=, -=, *=, /=, \=, ^=, and &= compound operators so that longer lines like:
can now be written as:
However, increment and decrement operators are not supported.
In prior iterations of Visual Basic, all statements in a condition would have been evaluated even if the outcome of the condition could be determined before evaluating a condition. For example:
Var* variable types are deprecated in Visual Basic .NET. The common runtime decides which types are reference types and which types are value types so this is no longer the domain of the programmer.
Class properties no longer require the Let and Set statements
DebugPrint is replaced with DebugWrite and DebugWriteLine
A procedure call must have parentheses in Visual Basic .NET.
Visual Basic .NET requires a ByVal or ByRef specification for parameters. In Visual Basic the specification could be omitted, implying ByRef by default. Most development environments, such as Visual Studio .NET, will automatically insert a ByVal, so in effect the default is ByVal, not ByRef. There are tools to convert Visual Basic code to VB.NET, such as the Visual Basic Upgrade Wizard that was included in Visual Studio .NET 2002 and 2003. Conversion tools automatically insert a ByRef if necessary, preserving the semantics of the Visual Basic application.
Visual Basic 5.0 and 6.0 has traditionally employed zero-based arrays (the default lower bound), unless "Option Base 1" is declared. This was the source of many out-by-one errors in Visual Basic programs, especially when dealing with interoperability across program library boundaries. Although the .NET Common Language Runtime can support arrays with any base value, Visual Basic .NET and C# provide only zero-based arrays and lists, and the .NET Common Language Specification requires zero-based arrays for interoperability between .NET languages.
Visual Basic .NET introduced the concept of a jagged array, whereby the rows can have unequal length as opposed to the uniform length of arrays imposed on Visual Basic programmers.
In languages compiling down to .NET platform, types are strict. Whilst the runtime allows for anonymous object which don't have a pre-defined, named type, the type of a variable may not change over the course of its life-time, hence the need to drop the Variant data-type. However, type "Object" has somewhat similar behavior in practice.
Visual Basic was an object-based language. It supported classes, but not other concepts that would make it an object-oriented language. Visual Basic .NET is a true object-oriented language with the following features:
Although no language targeting .NET allows for multiple inheritance for classes—multiple inheritance of interfaces is supported.
Whilst the IDE does a reasonable job of hiding the fact, the dependence on ActiveX objects is dropped in Visual Basic .NET (although there are mechanisms for interfacing with COM in .NET [2]) in favour of .NET components offering similar functionality. This shift is good for the Visual Basic developer since much of the performance issues in Visual Basic arose around the cost of the COM interface.
One of the true banes of a Visual Basic developer's life has always been writing resize code. Whilst the WinForms paradigm leaves a lot to be desired in the geometry management department in the face of toolkits like Qt and GTK+, at least the developer can anchor widgets on forms instead of having to write reams of code in OnResize handlers.
In Visual Basic .NET, Option Explicit is on by default.