Introducing .NET

Visual Basic

VB gets the most extensive changes of any existing language in the Visual Studio suite. These changes pull VB in line with other languages in terms of data types, calling conventions, error handling and, most importantly, object orientation.

We don't yet know for certain what the new Visual Basic will be called, but the current favorite is Visual Basic.NET. This label will be used in the discussion below.

Most new features in VB, especially the object-oriented ones such as inheritance, are courtesy of the CLR. Visual Basic.NET basically piggybacks on the stuff that was going to be implemented anyway for C++, C# and third party .NET languages.

Chapter 4 covers the changes to Visual Basic, especially the syntax changes, in detail. It also includes recommendations for coding practices that will make eventual migration to .NET easier. Here are a couple of highlights:

Lots of Possible Incompatibilities

These are the biggest changes ever in VB - bigger even than the jump from VB3 to VB4. This introduces significant potential for incompatibilities.

Here's one example. In the current implementation of .NET, all arrays are zero-based. There is no provision for explicit array bounds, so any code that uses them could require manual changes. There are quite a few other examples covered in Chapter 4.

Microsoft intends to supply a conversion tool, which will assist in porting VB6 projects to .NET, but it will not do everything required. There will be some areas where the conversion tool merely places a note that indicates something needs to be done. And there are likely to be areas where it fails to realize a change is needed at all.

Object Features

Many of us have been clamoring for Visual Basic to support full object-oriented development since classes were introduced in version 4. With Visual Studio.NET our wish comes true. VB now includes full inheritance, parameterized constructors, and control over property and method overriding.

C++

The most significant changes in C++ revolve around the concept of "managed code". A C++ developer has the option of marking a section of the code to be managed by the CLR. The language then provides:

• Metadata describing the modules into which the code is compiled
• Location of object references (no CoCreateInstance needed - just use New to declare an object)
• Exception handling tables

Managed code then allows the runtime to handle the following:

• Exception handling
• Security
• Lifetime management
• Debugging
• Profiling
• Memory management, including garbage collection

C++ developers have the option do everything the old way ("unmanaged code"), and this is, in fact, the default allowing extensive backward compatibility.

This book does not include a specific chapter on C++, but the concept of managed code is discussed in more detail in Chapter 2 on the Common Language Runtime.

The New C# Language

Currently, developers in the Microsoft world have two major choices - use Visual Basic to get fast development or use C++ to get more control.

C++ has traditionally been a tough choice to make for anything except system-level development and large-scale commercial products such as word processors. Even developers expert at C++ had to learn a ton of Microsoft macros and arbitrary constants in order to produce results. Microsoft attempted to shorten the development time required for VC++ user interfaces and COM objects by offering MFC and ATL, but VC++ development remained the province of an elite group of developers.

With Visual Studio.NET, Microsoft introduces C#, a new language that combines the power of C++ with the simplicity of VB. Despite its name, C# code looks a lot like Java code - gone is the C++ convention of separating class declarations and definitions into separate header (.h) and implementation (.cpp) files: in C#, as in Java, classes are declared and defined in the same code blocks. Also in C#, as in Java, even the primitive data types (integers, floats, etc.) are objects with methods that you can call for type conversions and output formatting. Furthermore, C#, like Java, is consistently object-oriented in that programs begin not at some global function external to all classes as in VB, but with a call to an object method defined as "public static void Main()". Last but not least, C# discourages you from using pointers.

All C# code is managed by the CLR. That makes C# leaner and safer than C++. C# also dispenses with bug-prone idioms such as multiple inheritance and pre-processor macros. To guard against the kinds of memory errors that are difficult to debug, the C# compiler issues warnings for variables that are referenced before being initialized. Recent, valuable C++ additions such as namespaces, the intrinsic string type, and structured error handling have been included in C#. Tricky C++ "gotchas" like fall-through switch...case have been eliminated.

Using the built-in capabilities of the CLR, C# makes implementing components easy. Doing COM objects in C++ meant generating interface GUIDS, implementing IUnknown and IClassFactory, and providing self-registration code. C# component development is like Visual Basic component development in that you simply implement a class and compile it, letting the C# compiler and the CLR provide the messy plumbing invisibly.

C++ has been described as a language that gives the programmer "enough rope to shoot himself in the foot." With C#, the developer has just as much rope, but he has to explicitly ask for it. For example, a programmer can short-circuit the CLR's automatic garbage collection, but only by explicitly prefixing object references with the fixed keyword.

C# is particularly well suited to .NET development. In many respects, it is just a version of the .NET object model that can be read by people. There is a large degree of correspondence between C# constructs and Microsoft Intermediate Language.

With its unique combination of power and simplicity, C# may well become the tool-of-choice for developing business objects, data access objects, and controls, thus pushing Visual Basic upward to Web Form-based user interfaces and C++ downward to hardcore middleware and other system level functions. On the other hand, since Visual Basic receives almost all of the functionality of C# in .NET, it may continue to be the dominant application development language by inertia. After all, there are literally millions of developers who know Visual Basic. Only time will tell what the acceptance level of C# will be.

However, there is one place that's jumping into C# with both feet - Microsoft itself. C# is the dominant language being used to develop the .NET framework, and it is quickly growing to be the most-used language at Microsoft. An introduction to C# is included in Chapter 3, and is also covered in the Wrox book, C# Programming with the Public Beta, ISBN 1-861004-87-7.

Language Changes Affecting ASP.NET

The successor to ASP is called ASP.NET. There are many changes and improvements. We have previously discussed Web Services and Web Forms, which are part of ASP.NET. Now we will look at some changes in writing traditional ASP pages.

For starters, VBScript is gone, though existing VBScript can still be run with the real Visual Basic compiler. That means VB code in Active Server Pages can now use real data typing (goodbye variants!) and such constructs as classes. JavaScript is still available, and is also compiled and then run through the CLR.

Also, the choice of languages is much enlarged. A COBOL vendor at PDC showed an Active Server Page in .NET with COBOL used for the code. Most languages that work with the CLR should be available for use in the .NET version of Active Server Pages.

As mentioned in the section above on the Common Language Runtime, code in Active Server Pages for .NET is actually compiled on the fly before it is run. This may help to cure some cases where interpreted script causes performance problems.

Chapter 7 gives a more detailed look at ASP.NET, and is written to be helpful also for developers who don't currently work with Active Server Pages.