• Chart: Visual Basic Developer Stacks
• Illustration: Data Access APIs in VB

When Visual Basic (VB) 6.0 moves from Mainstream to Extended support in Mar. 2005, it also marks the end of Mainstream support for a number of widely adopted technologies that have since been replaced by portions of the .NET Framework. Although this transition does not mean that existing applications will stop working, IT organizations need to understand which technologies are being phased out and know their successors. Furthermore, Visual Studio 2005 will contain features specifically designed to address difficulties VB developers have faced in moving to .NET, making this an opportune time for organizations to consider their VB development plans.

Technical Break from the Past

VB is the most popular programming product from Microsoft, and possibly the most widely used programming language from any vendor. VB gained its dominant position primarily as a tool for creating thick-client user interfaces that connected to a database. VB clients include both stand-alone applications and custom add-ons to Office applications created with the Visual Basic for Applications (VBA) tools built into the Office suite.

Microsoft has stopped supporting versions of VB in the past, so the impending retirement of support for VB 6.0, which was introduced in Jan. 1999, is no surprise. In past transitions, however, the latest version of VB could still be used to maintain applications built with earlier versions.

This transition is different. The successor to VB 6, VB.NET, marks a technical break with the past. VB.NET replaces most of the previous developer APIs with new .NET APIs and cannot be used to maintain pre-.NET applications. Each of the major APIs and components of the VB platform, including the programming language and base libraries, user interface libraries, and data access libraries—have undergone significant changes.

(For an overview of how these layers have changed since the introduction of VB, see the chart "Visual Basic Developer Stacks".)

Language and Base Libraries

Although the VB programming language has its roots in BASIC, it has been extended over the years as the audience for VB moved from hobbyist developers to IT professionals.

Classic VB. The classic VB language was built on BASIC but offered many language features not found in the original, including support for using objects with properties and events. However, as new features were added, VB carried over many anachronistic language features from earlier versions. Although this meant that existing code continued to run, making things easier for existing VB developers, it also complicated matters for new VB developers, who often struggled with the inconsistencies and apparent redundancies.

One example of this conflict was the distinction between the let and set keywords, both of which are used to assign a value to a variable: in some cases, the two are interchangeable, but in other cases they produce very different side effects.

VB also includes a set of APIs for such tasks as manipulating strings and reading and writing files. Although not technically part of the VB programming language, these APIs were an essential part of the overall VB developer experience.

VB.NET. In 2001, the classic VB language was replaced by VB.NET, which introduced the most sweeping language changes in the history of VB. In addition to adding major new language features, including support for the full object-oriented programming methodology, VB.NET eliminated many of the redundancies and overlapping features that had grown over the years. Given the magnitude of the changes, VB.NET was not backward-compatible with existing VB code. Future versions of VB, however, are expected to maintain compatibility with the VB.NET language so that code written today in VB.NET can be expected to work correctly even after the VB.NET tool is retired.

In addition to changes to the programming language, VB.NET switched from its own private set of standard libraries to the multilanguage libraries of the .NET Base Class Library (BCL). The BCL is, in many ways, superior to the built-in VB APIs—for instance, it encompasses more functionality and follows a style guideline designed by Microsoft to increase its maintainability over time. However, like the language itself, the BCL is not directly compatible with the previous VB APIs, and it presents another potential obstacle for developers seeking to make the switch to .NET.

VB in Visual Studio 2005. With Visual Studio (VS) 2005 (code-named Whidbey and expected in the first half of 2005), Microsoft is making further language enhancements to the VB API, including support for generics—a new feature (also available in C#) that enables programmers to build reusable classes (such as lists) that can be automatically customized to work with any type of data (producing a list of Customers and a list of Addresses, for example). But VS 2005 is also trying to make the BCL more accessible to VB programmers. The new "My Classes" APIs collect and simplify some commonly used but somewhat difficult to find functions of the BCL into a single namespace. Files can be read with one line of code that uses My.Computer.FileSystem, for example, instead of three lines of code that use System.IO.StreamReader.

The new APIs do not replace the BCL. Instead, they build on top of the BCL, making frequently used functions easier for VB developers to find and use.

User Interface

Apart from the VB programming language, the element of VB that most defined the VB experience was its user interface (UI) tools and libraries. Like the programming language, this UI has undergone significant changes in the move to .NET.

VB. The VB forms designer, known at Microsoft as Ruby, defined the basic metaphor for building user interfaces—controls were dragged onto a form, and double-clicking them took programmers to a code editor where they could write the code to be executed when a particular event is fired. Although the metaphor has survived the transition to .NET intact, the implementation is quite different and not compatible with Ruby.

VB.NET. With VB.NET, Windows Forms replaced Ruby. Like Ruby, Windows Forms provides a drag-and-drop environment and allows programmers to easily move from designing a form to editing the code for that form. But the specific details on the names of controls as well as the properties, methods, and events they offer, is quite different. Windows Forms, unlike Ruby, also supports programming languages other than VB.NET (it is also used by C#).

Some of the changes were made to support the multilanguage requirements of Windows Forms. But, as with the language changes, many of the UI changes were made to clean up some of the idiosyncrasies that had crept into Ruby over time. Once accustomed to Windows Forms, most developers will find it to be a significant improvement over Ruby, offering more functionality including support for sophisticated layout options and localizing forms into multiple languages. But making the transition could be difficult.

VS 2005 and beyond. The Windows Forms technology is implemented in VS 2005, but beyond that, its future is unclear. The next major revision of Visual Studio after VS 2005 is code-named Orcas and promises to support the next Windows client OS (code-named Longhorn), which will contain, among other things, a new UI framework (code-named Avalon). Although Microsoft has said that Avalon will interoperate with Windows Forms, it is clear from the technical material Microsoft has made available that Avalon is a fundamental change from Windows Forms; this casts doubt on the future of Windows Forms once Avalon ships.

This risk is somewhat offset by two factors. First, Longhorn is not expected until late 2006 and won’t be widely deployed in corporations or homes until even later. Second, even after Longhorn ships, VB will undoubtedly continue to support Windows Forms, allowing developers to continue to maintain Windows Forms applications even after Microsoft has stopped enhancing the framework itself.

Data Access

The most important feature in moving VB from the hobbyist to the IT professional market was the inclusion of a local database engine, along with the ability to easily build front ends to relational database systems. Even so, VB has had a somewhat checkered history of database access, with each release introducing a new database API and making another obsolete. (For an overview, see the illustration "Data Access APIs in VB".) VB.NET continued that tradition, but things seem to be taking a more hopeful turn in VS 2005.

Classic VB. When VB 3.0 was introduced in 1993, it included Jet, a high-performance indexed sequential access method (ISAM) database engine that was also used in Microsoft Access. At the same time, VB 3.0 introduced Data Access Objects (DAO), a COM interface to the Jet engine. Although DAO and Jet were immensely helpful to developers building local database applications, they didn’t help developers looking to build front ends to more sophisticated database systems, such as Oracle, DB2, and SQL Server.

In VB 4.0, the next major release of VB, Microsoft introduced another data access API. Like DAO, Remote Data Objects (RDO) was a COM interface. But unlike DAO, which built on top of a single database engine (Jet), RDO built on top of Open Database Connectivity (ODBC), a multivendor database API supported by Microsoft, Oracle, Sybase, and others. So, while DAO enabled VB developers to build local database applications, RDO brought VB into the world of client-server computing by making it simple for developers to build front ends to existing corporate databases.

As if the potential confusion around DAO and RDO weren’t enough, VB 5.0 offered yet another VB data access API: ActiveX Data Objects (ADO). ADO tried to provide a single API that could encompass local database engines (such as Jet), relational database systems (such as Oracle and SQL), and nonrelational database systems (including nondatabases, such as Excel spreadsheets). All of these technologies—DAO, RDO, and ADO— effectively became obsolete with the introduction of VB.NET.

VB.NET. VB.NET marked yet another transition in database APIs with the introduction of ADO.NET. Despite its similar name, ADO.NET is a new API and is not compatible with ADO. However, it does offer some significant advantages over ADO—most notably, it is designed to better support Web-based and three-tier applications, including the ability to incorporate XML data. But most important for VB developers growing weary of the past churn in database APIs, ADO.NET appears to be a stable base that customers can build on. (For more detailed information on ADO.NET and how it compares with its predecessors, see "ADO Redesigned for Web Architecture" on page 10 of the May 2002 Update.)

VS 2005 and beyond. VS 2005 will include ADO.NET 2.0. Although compatible with ADO.NET, this updated version addresses two needs. First, it contains extensions that make it suitable for use from code running within SQL Server. This is important because SQL Server 2005 (code-named Yukon) will allow developers to use any .NET language, not just Microsoft's SQL dialect, to write stored procedures, which execute on the database server. Second, ADO.NET 2.0 and VB 2005 include new database tools designed to simplify some common database tasks that inadvertently became more complex with VB.NET and ADO.NET, such as building simple forms that connect to a database and display the results of a query.

What’s an IT Developer to Do?

Ever since the introduction of VB.NET, VB developers have been trying to determine whether or not to make the jump to .NET and if so, when and how. Subsequent releases of VB.NET, along with Microsoft’s announced plans for VB 2005, make it clear the company is not retreating from the .NET Framework. In fact, with the eventual release of Longhorn, the .NET Framework continues to grow in importance, not shrink.

Two facts make the next 12 months an opportune time for holdout VB developers to make the jump: a carrot and a stick. The carrot is the release of VS 2005, due in the first half of 2005, which reduces some of the most obvious difficulties VB developers face in moving to .NET. First, it includes APIs designed to be familiar to VB developers (the My classes). Second, it has features missing from the original release of VB.NET—most notably Edit and Continue debugging—as well as the new tools for forms-based data access.

The stick is the fact that VB 6—the only tool capable of maintaining and enhancing existing VB applications—is exiting Mainstream support. This means that only corporations with support agreements will continue to have access to Microsoft support personnel and be able to get updates other than critical security fixes. Consequently, companies must carefully weigh the one-time cost of migrating to VB.NET versus the steadily increasing cost and risk of remaining on VB 6.

Resources

The VS 2005 homepage is msdn.microsoft.com/vstudio/Whidbey.

More details on some of the new features in VB 2005 can be found in "Visual Studio ‘Whidbey’ Details Emerge" on page 12 of the Oct. 2003 Update.

A preview version of VS 2005 is available to MSDN Subscribers at the MSDN Download Center at msdn.microsoft.com/subscriptions/downloads.