Visual Basic .NET: The Common Runtime and Early Releases

Visual Basic .NET was the language and development toolset produced when Microsoft brought Visual Basic onto the .NET platform. The year 2001 was a period of public testing and developer preparation: on 19 June, Bill Gates announced the availability of Beta 2 of Visual Studio .NET and the .NET Framework at the TechEd conference in Atlanta, explicitly including Visual Basic .NET. Microsoft wanted developers to use their existing language experience to build XML Web services capable of exchanging data and invoking functionality over networks.

The formal launch was a separate stage. On 13 February 2002, Gates launched Visual Studio .NET and the .NET Framework at the VSLive! conference in San Francisco. The announcement that day also stated that final versions had been available to MSDN subscribers since January. Public beta availability, subscribers' access to the final version and the public launch event therefore had different dates; 2001 should not be described generally as the year of the final release.

References: [1] [2]

The central problem addressed by this redesign was connecting different languages, components and application environments. In a technical article published in 2000, Jeffrey Richter explained that .NET used a common type system and the Common Language Runtime, or CLR. A Visual Basic compiler targeting this platform produced managed code, whose execution required the CLR rather than relying solely on the runtime support used by earlier Visual Basic versions.

Microsoft intermediate language and metadata in the compiled output represented, respectively, the operations to be executed and structural information such as types and members. The runtime used them to load types, resolve calls and convert code into a form executable by the machine. The common type system also allowed classes written in different languages to work together. Developers could thus retain the idioms of a particular language while using cross-language components and class libraries, without having to supply an entire separate set of functions for each language.

References: [3]

Class inheritance was a concrete expression of this change. Paul Vick's early language book used customers and employees as an example: both kinds of object needed names and addresses. Rather than repeatedly declaring those fields, a developer could create a Person class and derive Customer and Employee from it, adding a customer number or salary respectively. The statement “Inherits Person” expressed a relationship between types, rather than copying unrelated source code.

A procedure taking a Person parameter and displaying a name and address could consequently handle a customer or an employee as well. Calling code did not need to repeat the same logic for every specific role. This did not erase type boundaries, however: when treating an object as a Person, code could not directly access a salary field belonging only to Employee, and an employee object did not become a customer merely because the conversion syntax changed. Visual Basic .NET also limited a class to a single direct base class.

References: [4]

In June 2001, Ken Spencer demonstrated the uses of form inheritance in MSDN Magazine. When several company forms needed the same logo, buttons and positioning, a developer could first design a base form and derive others from its interface and behaviour. An ordinary template chiefly reduced the initial drawing work; inheritance organized shared elements in one base class so that they could be maintained centrally.

This depended on a key fact: a Windows Forms form was itself a class, so controls could be positioned in a designer while class-inheritance rules were also applied. The example did not mean that changing the parent form would automatically update every deployed application. Spencer specifically warned that a project using a local copy of the base-class assembly had to update that copy before derived forms could acquire the changes. Design-level reuse still had to be coordinated with actual deployment.

References: [5]

At the 2002 launch, Visual Basic .NET product-unit manager Rob Copeland demonstrated a service that looked up books by ISBN. He created an ASP.NET Web service in the development environment, dragged a database table into the designer, and configured a connection, a data adapter and a stored procedure filtering by ISBN. The tools performed part of the connection and data-mapping work, while the programmer still had to specify query criteria and externally exposed methods.

A text box on a Web page then accepted an ISBN, and a button event called the service and placed the returned book title and price on the page. The debugger could also step through calls between the page, the service and the database stored procedure. This illustrated the product team's intended use at the time: visual development would no longer revolve solely around desktop forms, but would help business applications span client, server and data layers. It was a feature demonstration, not direct proof that all real projects could achieve the same development speed.

References: [6]

Rebuilding the platform also imposed compatibility costs. Early product-help documentation for Visual Studio 2003 explicitly explained that the Upgrade Wizard would create a separate Visual Basic .NET project while preserving the original Visual Basic 6.0 project; the new project could not be reopened in the older version. The tool converted some syntax and forms, and generated a report and to-do comments identifying areas still requiring manual changes. Automatic conversion was therefore only one part of migration.

Data types offered an easily overlooked example: Integer had been 16-bit in the older version, whereas Integer in .NET mapped to the 32-bit System.Int32; former 16-bit uses required consideration of Short. Particularly when calling older components or external procedures, identical names did not guarantee identical data widths. Taken together with inheritance, the common runtime and service development, these changes expanded ways of organizing and reusing programs while requiring developers to re-examine boundaries, deployment and compatibility.

References: [7]