Introducing .NET

The major benefits of .NET discussed thus far can be summarized as:

• Faster development (less to do, the system handles more)
• Lots of built-in functionality through a rich object model
• A variety of ways to interface and integrate with the outside world
• More reuse
• Easy to integrate different languages into one system
• Easier deployment
• Scalability
• Easy to build sophisticated development tools
• Interfaces well to existing software

There are a couple of additional benefits that are worth mentioning.

Fewer Bugs - Whole Classes of Bugs Will Disappear

The architecture and capabilities of the CLR wipe out whole classes of bugs. Memory leaks, failure to clean up at the end of execution, and other memory management related problems become non-existent (assuming the developers of the CLR take care of their part). Instancing of classes is handled automatically (no more CoCreateInstance), and they are managed throughout their lifecycle.

Potentially Better Performance

The built-in capabilities of the CLR are to be used almost universally. Microsoft knows that, for .NET to succeed, these capabilities must be reliable and efficient, and they have invested the efforts of their very best architects and developers to make that happen.

This heavy investment in system level code should have the result of speeding up performance for all but the most optimized of applications. Critical and frequently used functions, no matter how ordinary, will usually be optimized to the hilt in the CLR.

Some Potential Downsides

Nothing comes completely for free. Here are a couple of ways in which there is a price to be paid to get the advantages of .NET

Language Incompatibilities

Making languages work in this new framework usually means adjustment to the language syntax. This introduces compatibility problems in moving existing code into .NET. Visual Basic is a particular problem, as we shall see in Chapter 4.

Transparency of "Source Code"

The bytecodes in the Intermediate Language are much higher level than the processor instructions that programs are compiled into today. While we can disassemble a program in current environments, the assembler-based result is of limited use. .NET programs disassembled from IL, on the other hand, will more closely resemble actual source code. They will also contain the information needed to understand data structures. Such disassembled programs make algorithms and code processes more transparent than with current environments, making it more difficult to protect intellectual property. Microsoft may eventually build in some kind of encryption to remedy this problem, or perhaps third parties can introduce tools that obfuscate the code, but there are no known plans at this point.

The First Step - Visual Studio.NET

The first technology to be released in the .NET framework will be the next generation of Visual Studio, which has been tagged Visual Studio.NET. It will include Visual Basic, Visual C++, and C# (the new language from Microsoft discussed below). Visual FoxPro is included in beta one of Visual Studio.NET, but the final status of this as a .NET language is not known at the time of writing.

Microsoft has been hinting for several months about what's going to be new in Visual Studio. Here are some of the confirmed changes and new features, as of beta one - keeping in mind that things can change before release.

Common IDE for All Languages

Microsoft has gradually been melding the Integrated Development Environment (IDE) for all their languages into one code base. In Visual Studio 6, Visual Basic was the last major holdout. That process is now complete, and the exact same IDE is to be used for all languages in the Visual Studio.NET suite.

However, a potentially bigger change is that Microsoft has completely opened up the IDE for other languages. Any third party language vendor can license the technology to have the language work within the .NET framework and place their language in the Visual Studio IDE. At least twenty languages are under consideration for such integration, including everything from Eiffel to COBOL.

Fully supporting a third party language in the .NET Framework, and thus Visual Studio, will require a lot of work. The vendor must create a compiler for the language that produces Intermediate Language bytecode instead of native machine code. The language's data types must be rationalized with the ones supported by the CLR. But the language vendor gets a lot in exchange, including an advanced development environment, plus debugging tools and complete cross-language integration.

Chapter 5 will look at the new Visual Studio IDE, and cover other new features of Visual Studio in more depth and detail.

The Common Language Specification

Languages that fit into.NET must satisfy the Common Language Specification (CLS), which sets the constraints the languages must meet. If a language adheres to this spec, it gets an appropriate level of language interoperability.

All .NET Languages Are Not Created Equal

There are actually three categories of compliance to the CLS that .NET languages can subscribe to. Briefly they are:

• Compliant producer - The components in the language can be used by any other language.
• Consumer - The language can reuse classes produced in any other language. This basically means the ability to instantiate classes in the way that, for example, scripting languages can instantiate COM objects today.
• Extender - Languages in this category can do more than just instantiate classes - they can also extend those classes using the inheritance features of .NET.

All the confirmed languages in the Visual Studio suite (VB, VC++, C#) are expected to satisfy all three categories of the CLS. Third party languages can select the levels of compliance that make sense for them.

Management of Multiple Language Projects

Since any number of languages can now be used in a project, the Visual Studio IDE will now look at projects in terms of all the modules being used, no matter what language they are in. The project explorer (actually called the Solution Explorer) is the same no matter what combination of languages is used.

Absence of Visual Interdev and J++

Visual Studio.NET does not have a separate piece identified as Visual Interdev. In effect, the functions of Visual Interdev have migrated into the IDE as a whole. There is an HTML editor, for example, which works across the whole IDE, and the new Solution Explorer bears a strong resemblance to the Resource Window in Interdev.

Also, Web Forms have basically taken the place of the drag-and-drop visual designer in Interdev, and have the advantage of working with any language.

J++ is gone for a different reason. Microsoft's continuing legal troubles with Sun have frozen Java-related efforts at Microsoft. The current J++ will be supported, but it cannot be enhanced and placed in the new Visual Studio at this point. In a sense, C# takes its place (more on that below), but it's possible that a real Java implementation from a third party will be available at or near Visual Studio.NET's release.

Chapter 5 covers more details on the changes and new features in Visual Studio.NET. It analyses the new IDE, and includes example screens to illustrate the changes.