A First Look at VB 7.0 and the .NET Framework
- A First Look at VB 7.0 and the .NET Framework
- A New Ballgame
- Summary
Abstract: Dan Fox takes a look at what is on the horizon for the next version of Visual Basic, and how it relates to Microsoft's new .NET initiative.
Regular readers of InformIT have no doubt already noticed the coverage of Microsoft's newest language, C#. As a result, you're aware that C# will debut in the next release of Microsoft Visual Studio, version 7.0, tentatively referred to as Visual Studio .NET. What you may not be aware of is that much of the power and the features found in C# will also make their way into VB 7.0 (or VB .NET, if you prefer). In this article, I'll take you through a few of those features and show you how VB takes advantage of the Microsoft .NET Framework. Before I get started, I should note that the code in this article was built with the PDC Tech Preview version of VS 7.0, the core of which can be downloaded from MSDN at http://msdn.microsoft.com/sdfsfdsdf. As a result, any of the specifics discussed here are liable to change before the product is released.
Sometimes Less Is More
To be sure, the most interesting aspect of VB 7.0 is that it derives its core features from the .NET Framework (formerly known as Next Generation Windows Services or NGWS). Simply put, the .NET Framework provides a set of class libraries and a run-time engine that multiple languages share. From this perspective, you can think of Visual Basic as one of many possible wrappers around the .NET Framework, with very little, other than syntax and program structure, that is VB-specific. However, as you'll see, far from restricting VB, this architecture allows VB to extend itself all the way across the enterprise.
Perhaps the most important feature of the .NET Framework is its class libraries. The class libraries are grouped together in namespaces and are supplied to allow consistent access to system services. The class libraries encapsulate and abstract everything from the low-level operating system services such as IO to high-level services such as messaging using MSMQ. This architecture should make life easier by providing a well-debugged and reusable set of classes. This feature alone should be a boon to VB developers who frequently amass their own code libraries to deal with thorny Win32 issues or services such as string manipulation, sorting and searching, and hashing.
Using a class library also affords simplicity since a developer needn't use a combination of Win32 API calls and COM objects, each with their own sets of rules. A particularly good example of classes that provide these benefits are found in the System.Net namespace. This namespace includes classes that provide services to allow applications to communicate over the Internet using HTTP and FTP. An additional benefit that should be apparent is that by releasing new classes, VB developers can easily take advantage of new system services. For example, the incorporation of the ASP+ technologies into class libraries allows VB to easily create web applications without reliance on propriety schemes such as the Web classes and Dynamic HTML projects introduced in VB 6.0. The classes within the libraries are also object oriented and, as a result, can be extended by a developer through inheritance when implementing specific features. The PDC version of the .NET Framework ships with references to 87 different namespaces that comprise hundreds of classes. A small sampling of these namespaces (adapted from Jeffery Richter's article on MSDN at http://msdn.microsoft.com/msdnmag/issues/0900/framework/framework.asp) can be seen in the following table.
|
Purpose |
Namespace |
Example Classes |
|
Provides basic types, top-level namespace |
System |
Object, Buffer, Byte, Char, Array, Int32, Exception, String |
|
Managing collections of types |
System.Collections |
ArrayList, BitArray, Dictionary, Hashtable, Queue, SortedList, Stack |
|
Accessing data through ADO+ |
System.Data |
DataBinding, DataRelation, DataRow, DataSet, DataTable, DataSource |
|
Resource for internationalization |
System.Globalization |
Calendar, CultureInfo, JulianCalendar, NumberFormatInfo, NumberStyles, RegionInfo |
|
Reading and writing data through streams |
System.IO |
ByteStream, File, FileStream, MemoryStream, Path, StreamReader, StreamWriter |
|
Accessing resources over the network |
System.Net |
WebRequest, WebResponse, TcpClient, TcpListener, UdpClient, Sockets |
|
Implementing security using authentication and encryption |
System.Security |
Permissions, Policy, Principal, Util, Cryptography |
|
Implementing UI controls for web-based applications |
System.Web.UI.WebControls |
AdRotator, BorderStyle, DataGrid, HyperLink, ListBox, Panel, RadioButton, Table |
|
Providing a shared forms package for desktop applications |
System.WinForms |
Button, CheckBox, DataGrid, FileDialog, Form, ListBox, MainMenu, MonthCalendar, NewFontDialog, RichEdit, ToolBarTreeView |
|
Using timers and scheduling |
System.Timers |
Timer, Schedule, DailyPattern, MonthlyPattern, RecurrencePattern |
|
Creating multithreaded applications |
System.Threading |
Monitor, Mutex, Thread, ThreadPool, Timer |
The second core feature of the .NET Framework is the use of a common run-time engine. All applications compiled to use the run-time produce "managed code", as opposed to "unmanaged code" produced by the current generation of the development tools. VB 7.0 will only produce code that uses the run-time and hence only managed applications. In other words, instead of VB apps calling into the infamous VB runtime (msvbvm60.dll for example), they will instead call into a run-time engine shared by VC++, C#, JScript, and Visual FoxPro for starters, although among these, VC++ will also be able to produce unmanaged executables. Microsoft will also release a standard dubbed the Common Language Specification (CLS) that will allow other vendors to produce compilers that work with the .NET run-time.
The architecture of the .NET run-time (found in MSCorEE.dll) is significantly different from what VB developers are used to. For example, rather than produce a native executable, VB 7.0 will produce a Portable Executable (PE) file that contains a CPU-independent machine language called MSIL. Although I can almost hear the crashing hopes of many seasoned VB developers as they recall the time and sweat that it took for native compilation to finally make it into VB 5.0, rest assured the benefits of an intermediate language executable are significant. For starters, as expected MSIL provides the benefits of hardware abstraction and security that developers can take advantage of if the .NET run-time is ported to other platforms and new versions of Windows (64 bit). However, the .NET run-time also uses Just-In-Time (JIT) compilation to offset the performance penalty normally invoked when compiling an application as it is loaded. To further increase performance, the JIT compiler can also take advantage of particularities in the machine state (such as CPU type) or patterns in program data when the application runs to increase performance at run-time. Expect improvements such as these to be made incrementally as Microsoft refines the run-time engine.
Aside from performance, the run-time also provides several other features. For example, since the .NET run-time is shared by multiple languages, it also provides the ability for those languages to reuse code from one another. For example, a class created in C# can be extended through inheritance in VB to provide additional functionality. This integration also makes it possible to do cross-language debugging more easily through a common debugger. The run-time is also object oriented and provides object creation and management facilities (referred to as the Virtual Object System or VOS) exposed through the System.Object class. The VOS is in many ways analogous to the COM system libraries that are currently a part of Windows, although VOS's inclusion in the run-time makes them more portable and self-contained. Other general benefits of the run-time include features that VB developers are familiar with such as type safety and garbage collection.
While the run-time provides the underlying architecture, the .NET Framework also changes the way you'll view applications. In an effort to eliminate the most persistent support headaches, the scheme for packaging and deploying applications has altogether changed. An application is now deployed as a collection of files referred to as an "assembly" that includes its own self-referencing "manifest", which contains references to all the resources, down to the particular version, that the application needs. This scheme allows the run-time to load the appropriately versioned classes for the application. As a result, all applications built in VB 7.0 will have everything they need to run correctly when deployed to a different machine. Although there are subtle variations, by and large applications can be deployed simply by copying a directory structure to a new machine. This scheme also alleviates the "DLL Hell" problem that occurs when an application overwrites a DLL upon which another application is dependent. In addition, the inclusion of the VOS means that applications no longer need to rely on the registry for COM component creation, a continual source of confusion for developers and users. While some hail this as the "death of COM", it is still possible to call unmanaged COM components from VB 7.0.
As mentioned above, VB can be thought of merely as packaging over the .NET Framework. In the remainder of this article, we'll explore the packaging to see how VB exposes the features of the .NET Framework.