The philosophy of .NET. (A Revelation of .NET).

There is probably no software development in the last years that has not been regarded with such caution as .Net. Caution because its source is Microsoft, regarded by many as at times `economical with the truth' whose business model is a complex of altruism and hard marketing. `Visual Basic.Net and the .Net Platform' is a professionals guide to .Net applications and is available in conjunction with a source code book that is available as a download from the publisher !apress .In addition to this the reader needs to have a copy of .Net Beta 2. The book focus is largely on using the Visual Studio. Net development environment and is clearly produced for the serious user with solid background in a modern programming language (Visual Basic,C++,Java,etc). Having said that,it is produced in a style that initiates the reader into the new system by building on their current general know ledge. Now read on. The Editor

(The book is dedicated to those who died on Sept 11th 2001)

Every few years the modern-day programmer must be willing to perform a self-inflicted knowledge transplant to stay current with new technologies. The languages (C++, Visual Basic 6.0, Java), frameworks (MFC, ATL, STL) and architectures (COM, CORBA) that were touted as the silver bullets of software development eventually become overshadowed by something better or new. Regardless of the frustration you may feel as you upgrade your knowledge base, it is unavoidable. Microsoft's.NET platform represents the next major wave of (positive) changes coming from those kind folks in Redmond.

The point of this chapter is to lay the conceptual groundwork for the remainder of the book. It begins with a high-level discussion of a number of .NET-related atoms such as assemblies, intermediate language (IL), and just-in-time (JIT) compilation. During the process, you will come to understand the relationship between core aspects of the NET framework, such as the Common Language Runtime (CLR), the Common Type System (CTS), and the Common Language Specification (CLS).

This chapter also provides an overview of the functionality supplied by the .NET base class libraries and examines helpful utilities (such as ILDasm.exe) that you can use to investigate these libraries at your leisure.

Understanding the Current State of Affairs

Before examining the specifics of the NET universe, it's helpful to consider some of the issues that motivated the genesis of this new platform. To get in the proper mindset, let's begin this chapter with a brief(and painless) history lesson to remember the roots of windows development and understand the limitations of the current state of affairs (after all, admitting you have a problem is the first step toward finding a solution). After this quick tour of life as we know it, we turn our attention to me numerous benefits provided by the VB .NET programming language and the .NET platform.

Life As a Win32/C Programmer

Traditionally speaking developing software for the Windows operating system involved using the C programming language in conjunction with the Windows API (application programming interface). While it is true that numerous applications have been successfully created using this time-honored approach, few would disagree that building applications using the raw API is a complex undertaking. The first problem is that C is a very terse language. C developers are forced to contend with manual memory management, ugly pointer arithmetic, and awkward syntactical constructs. Furthermore, given that C is a structured language, it lacks the benefits provided by the object-oriented approach (can anyone say spaghetti code?). When you combine the thousands of global functions defined by the raw Win32 API to an already formidable language, it is little wonder that there are so many buggy applications floating around today.

Life As a C++/MFC Programmer

One vast improvement over raw C development is the use of the C++ programming language. In many ways, C++ can be thought of as an object-oriented layer on top of C. Thus, even though C++ programmers benefit from the famed "pillars of OOP" (encapsulation, polymorphism, and inheritance), they are still at the mercy of the painful aspects of the C language (i.e., memory management, ugly pointer arithmetic, and awkward syntactical constructs). Despite the inherent complexity, many C++ frameworks exist today. For example, the Microsoft Foundation Classes (MFC) provide the developer with a set of existing C++ classes that facilitate the construction of windows applications. The main role Of MFC is to wrap a "sane subset" of the raw Win32 API behind a number of classes, magic macros, and numerous GUI tools (e.g., AppW!zard, ClassWizard, and so forth). Regardless of the helpful assistance offered by the MFC framework (as well as many other windowing toolkits), the fact of the matter is that C++ programming remains a difficult and error-prone process, given its historical roots in C.

Life As a Visual Basic 6. 0 Programmer

In an effort to enjoy a simpler lifestyle, many programmers have shifted away from the world of C(++) -based frameworks to kinder, gentler languages such as Visual Basic 6.0 (VB). VB is popular due to its ability to build complex user inter- faces, code libraries (e.g., COM servers), and data access logic with minimal fuss and bother. Even more than MFC, VB hides the complexities of the Win32 API from view using a number of integrated GUI tools, intrinsic data types, classes, and VB-centric functions.

The major downfall of VB (at least until the advent of VB NET) is that it is not a fully object-oriented language, but rather "object aware." For example, VB 6.0 does not allow the programmer to establish "is-a"relationships between types (i.e., no classical inheritance), has no support for parameterized class construction, no intrinsic support for building multithreaded applications, and so on. As this book shows, VB .NET removes all such limitations.

Life As a Java Programmer

Enter Java. The Java programming language is a completely object-oriented entity that has its syntactic roots in C++. As many of you are aware, Java's strengths are far greater than platform independence. Java as a language cleans up the unsavory syntactical aspects of C++. Java as a platform provides programmers with a large number of predefined "packages" that contain various class and interface definitions. Using these types, Java programmers are able to build "100% Pure Java" applications complete with database connectivity, messaging support, Web-enabled front ends and rich-user interfaces (in addition to other services).

Although Java is a very elegant language, one potential problem is that using Java typically means that you must use Java front-to-back during the development cycle. In effect, Java offers little hope of language independence, as this goes against the grain of Java's primary goal (a single programming language for every need). In reality there are millions of lines of existing code in the world that would like to comingle with newer Java code. Sadly, Java doesn't make this easy.

On a related note, Java alone is not appropriate for every situation. If you are building a graphics intensive product (such as a 3D-rendered video game), you'll find Java's execution speed can leave something to be desired. A better approach is to use a lower-level language (such as C++) where appropriate, and have Java code interoperate with the external C++ binaries. While Java does provide limited ability to access non-Java APIs, there is little support for true cross-language integration.

Life As a COM Programmer

The troth of the matter is if you are not currently building Java-based solutions, the chances are good that you are investing your time and energy understanding Microsoft's Component Object Model (COM). COM is an architecture that says, in effect, "If you build your classes in accordance with the rules of COM, you end up with a block of reusable binary code."

The beauty of a binary .COM server is that it can be accessed in a language independent manner. Thus, C++ programmers can build coclasses that can be used by VB. Delphi programmers can use coclasses built using C, and so forth. However, as you may be aware, COM's language independence is limited. For example, there is no way to derive a new COM type using an existing COM type (no support for classical inheritance). Rather, you must make use of the less robust "has-a" relationship to reuse existing COM types.

Another benefit of COM is its location-transparent nature. Using constructs such as application identifiers (AppIDs), stubs, proxies, and the COM runtime environment, programmers can avoid the need to work with raw Sockets, RPC (remote procedure calls), and other low-level details. For example, ponder the following Visual Basic 6.0 COM client code:

`This block of VB 6.0 code can activate a C0M
class written in
`any C0M aware language, which may be
located anywhere
`on the network (including your local
machine),
Dim c as MyCOM Class
Set C=New MyCOMClass `location resolved
using AppID.
c. DoSomeWork

Although COM is a dominant object model, it is extremely complex under the hood (at least until you have spent many months exploring its plumbing ... especially if you happen to be a C++ programmer). To help simplify the development of COM binaries, numerous COM-aware frameworks have come into existence. For example, the Active Template Library (ATL) provides another set of C++ predefined classes, templates, and macros to ease the creation of classic COM types.

Many other COM-aware languages (such as Visual Basic 6.0) also hide a good part of the COM infrastructure from view. However, framework support alone is not enough to hide the complexity of classic COM. Even when you choose a relatively simply COM-aware language such as Visual Basic 6.0, you are still forced to contend with fragile registration entries and numerous deployment-related issues.

Life As a Windows DNA Programmer

Finally there is a little thing called the Internet. Over the last several years, Microsoft has been adding more Internet-aware features to its family of operating systems. It seems that the popularity of web applications is ever expanding. Sadly, building a complete Web application using Windows DNA (Distributed iNternet Architecture) is also a very complex undertaking.

Some of this complexity is due to the fact that Windows DNA requires many technologies and languages (ASP, HTML, XML, JavaScript, VBScript, COM(+), and a data access technology such as ADO). One problem is that many of these items are completely unrelated from a syntactic point of view. For example, JavaScript has a syntax much like C, while VBScript is a subset of Visual Basic proper. The COM servers that are created to run under the COM+ runtime have a very different look and feel from the ASP pages that invoke them. The end result is a highly confused mishmash of technologies. Furthermore, each language and/or technology has its own type system (that looks nothing like the other type systems). An "int" in Javascript is not the same as an "Int" in C, which is different from an "Integer" in VB 6.0

The .NET Solution

So much for the brief history lesson. The bottom line is life as a Windows programmer is tough. The. NET framework is a radical and brute-force approach to making your life easier. The solution proposed by .NET is "Change everything from here on out" (sorry, you can't blame the messenger for the message). As you will see during the remainder of this book, the. NET framework is a completely new model for building systems on the Windows family of operating systems, and possibly non-Microsoft operating systems in the future. To set the stage, here is a quick rundown of core features provided courtesy of .NET:

* Full interoperability with existing code. This is (of course) a good thing. As shown in Chapter 13, existing COM binaries can comingle (i.e., interop) with newer.NET binaries and vice versa.

* Complete and total language integration. Unlike classic COM, .NET supports cross-language inheritance, cross-language structured exception handling, and cross-language debugging.

* A common runtime engine shared by all.NET aware languages. One aspect of this engine is a well-defined set of types that each.NET-aware language "understands."

* A base class library that provides shelter from the complexities of raw APl calls, and offers a consistent object model used by all .NET-aware languages.

* No more COM plumbing! IClassFactory, IUnknown, IDL code, and the evil VARIANT-compliant types (BSTR, SAFEARRAY, and so forth) have no place in A.NET binary.

* A truly simplified deployment model. Under.NET, there is no need to register a binary unit into the system registry. Furthermore, the NET run time allows multiple versions of the same DLL to exist in harmony on a single machine.

Building Blocks of .NET (CLR, CTS, and CLS)

Although the roles of the CLR, CTS, and CLS are examined in greater detail later in this chapter, you do need to have a working knowledge of these topics to make sense of the.NET universe. From a programmer's point of view,.NET can be understood as a new runtime environment and a common base class library. The runtime layer is referred to as the Common Language Runtime, or CLR. The primary role of the CLR is to locate, load, and manage NET types on your behalf. The CLR takes care of a number of low-level details such as automatic memory management and language integration. The CLR also assists with simplified deployment (and versioning) of binary code libraries. Another building block of the.NET platform is the Common Type System, or CTS. The CTS describes all possible data types (and constructs) supported by the runtime, specifies how those types can interact with each other, and details how they are represented in the NET metadata format (more information on `meta-data' later in this chapter). Understand that a given .NET-aware language might not support each and every data type and/or construct defined by the CTS. The Common Language Specification (CLS) is a set of rules that defines a subset of common types that ensure NET binaries can be used seamlessly across all languages targeting the .NET platform. Thus, if you build.NET types that only expose CLS-compliant features, you can rest assured that all.NET-aware languages could make use of your custom types.

The NET Base Class Libraries

In addition to the CLR and CTS/CLS specifications, the NET platform provides a base class library that is available to all NET programming languages. Not only does this base class library encapsulate various primitives such as file 10, graphical rendering, and interaction with external hardware devices, but it also provides support for a number of services required by most real world applications. For example, the base class libraries define types that support database manipulation, XML integration, programmatic security, and the construction of Web-enabled (as well as traditional desktop and console-based) front ends. From a conceptual point of view, you can visualise the relationship between the.NET runtime layer and the corresponding base class library as shown in Figure 1 - 1.

[FIGURE 1 - 1 OMITTED]

.NET-Aware Programming languages

When the.NET platform was announced to the general public during the 2000 Professional Developers Conference (PDC), several speakers listed vendors who are busy building. NET-aware versions of their respective compilers. At the time of this writing, more than 30 different languages are slated to undergo .NET enlightenment. In addition to the four languages that ship with Visual Studio .NET (C#, Visual Basic.NET, "Managed C++," and JScript.NET), be on the lookout for.NET versions of Smalltalk, COBOL, Pascal, Python, PLI, and Peri.

Regardless of which language you choose, the end result is a binary DLL or EXE file. The funny thing about the. NET binaries produced by a given compiler is that despite the fact they take the same file extensions (DLL or EXE) as classic COM binaries, they have absolutely no internal similarities. For example: NET DLLs do not export methods to facilitate communications with the classic COM runtime (given that. NET is not COM). Furthermore, NET binaries are not described using type libraries and are not registered into the system registry. Perhaps most important, unlike classic COM servers, NET binaries do not contain platform-specific instructions. Instead they include platform-agnostic "intermediate language" officially termed Microsoft Intermediate Language (MSIL) or simply, IL. Conceptually, Figure 1-2 shows the big picture.

[FIGURE 1 - 2 OMITTED]

Given that .NET is such a radical departure from current thinking, it should be clear that the current programming languages (VB 6.0, C++, C, and whatnot) are incapable of producing code that targets the .NET runtime. As time marches on, more and more modern day languages will achieve .NET enlightenment. Recall, Visual Studio (see page 00) .NET already provides you with four languages

A Brief Word Regarding C#

C# is a brand-new programming language, specifically designed to build .NET binaries. Like Java, C# has roots in the syntax of C++. However, a number of C#'s syntactic constructs are modeled after various aspects of Visual Basic. For example, like Visual Basic 6.0, C# supports the notion of class properties, "for each" like iteration and type indexers. On the other hand, like C++, C# allows you to over- load operators for a custom type as well as create "unsafe" code blocks that bypass the CLR. Given that C# is a hybrid of numerous languages, the end result is a product that is as syntactically clean (if not cleaner) than Java, just about as simple as Visual Basic, and provides just about as much power and flexibility as C++ (without the associated ugly bits).

Although an experienced Visual Basic developer should be able to view C# code without too much pain, be aware that the syntax of C# is a bit on the terse side. For example, assume you are using C# to define a class property called First- Name. The code block looks like the following:

//C#. Assume fName is a private member
//variable of type string.
public string FirstName()
{
get{return fname;}
set{fName = value;}

The same property is expressed in VB NET as follows:

`VB NET. Also assume that fname is a private
`String.
Public Property FirstName() as String
Get
Return fName
End Get
Set(ByVal Value as String)
FName = Value
End Set
End Property

At this point in the game, do not concern yourself with the exact syntax of the FirstName property (in either language). Do notice, however, that the VB .NET version is constructed using readable, user-friendly keywords (e.g., Property, End Get, End Set) rather than the more C++-like curly brackets ({and}) and semicolons.

As you see later in this chapter, the underlying IL emitted by each compiler is identical. In this light, the programming language you choose to build your managed application becomes little more than a personal choice. If you have a solid background in the BASIC family of languages, the chances are you will feel much more at home with the syntax of VB .NET. On the other hand, if an individual is already comfortable using languages that come from the C++ family (such as Java or C++ itself), C# is a more natural fit. As you might expect, once you are familiar with the syntax of one. NET-aware programming language, it is relatively simple to read code written in another managed language. While this text focuses on the syntax of VB .NET, 1 show C# examples where appropriate.

What VB .NET Brings to the Table

Assuming you have decided to adopt VB .NET, you can rest assured that you have made an intelligent choice. Unlike previous editions of Visual Basic, VB .NET provides the same level of syntactic expression found in other object-oriented programming languages. For the first time in VB's 10-year history, you can build complete, feature-rich, 00 applications. To wet your appetite, here is a quick rundown of some (but not all) of the features provided by Visual Basic .NET.

* Complete object orientation. VB programmers can now make use of classical inheritance, method overloading, and classical polymorphism.

* Improved error handling. To be blunt, error handling in earlier versions of VB was awful. Although you are free to make use of the infamous "On Error Goto" syntax, VB .NET now supports structured exception handling.

* Parameterized class construction. No longer are you forced to build ad hoc methods to hydrate your custom types. VB .NET now supports type constructors (which can take any number of parameters).

* Support for building multithreaded applications. Attempting to build multithreaded applications in #B 6.0 was a dark, dreary process. Although it was possible to spawn a secondary thread of execution, you were required to bypass the VB runtime layer to do so. Not only was this dangerous, it was unnecessarily complex.

* Full support for interface-based programming techniques. Unlike classic COM, the interface is not the only way to manipulate types between binaries. .NET supports true object references that can be passed between boundaries (by reference or by value).

* Finally, VB .NET cleans up many unsavory aspects of VB 6.0's syntax (as you see over the course of this text).

Perhaps the most important point to understand about the VB .NET language is that it is only capable of producing code that can execute within the .NET run-time (you could never use VB .NET to build a classic COM server). Officially speaking, the term used to describe the code targeting the .NET runtime is managed code. The conceptual unit that contains the managed code is an assembly.

Visual Basic .NET and the .NET Platform: An Advanced Guide

ISBN (pbk): 1-893115-26-7

Apress 901 Grayson Street, Suite 204 Berkeley, CA 94710. Phone [phone], fax:[phone], email [e-mail].

The source for this book is available to readers at http://www.apress.com in the Downloads section. You will need to answer questions pertaining to this book in order to successfully download the code.

Contact the Editors e-mail on 106142.1713@compuserve. com