Overview of the .NET Framework

Overview of the .NET Framework
Clearly, a considerable amount of infrastructure is required to make XML Web
Services transparent to the developers and users. The .NET Framework
provides that infrastructure. To the .NET Framework, all components can be
XML Web Services, and XML Web Services are just a kind of component. In
effect, the .NET Framework takes the best aspects of the Microsoft
Component Object Model (COM) and combines them with the best aspects of
loosely coupled, XML-based computing. The result is a powerful, productive
Web component system that simplifies programmer plumbing, deeply integrates
security, introduces an Internet-scale deployment system, and greatly
improves application reliability and scalability.

The .NET Framework consists of two main parts: the Common Language Runtime
(CLR) and a set of unified class libraries. The class libraries include
versions of many of Microsoft's existing development technologies, such as
an advanced version of Active Server Pages, called ASP.NET, a set of
classes for rich user interface development, called Windows Forms, and a
data-access subsystem called ADO.NET. All these existing libraries have
been updated to be XML aware within the .NET Framework.

The Common Language Runtime
Despite its name, the Common Language Runtime actually has a role in a
component's development time and runtime experiences. While the component
is running, the runtime is responsible for managing memory allocation,
starting up and killing threads and processes, enforcing security policy,
and satisfying any dependencies that the component may have on other
components. At development time, the runtime's role changes slightly.
Because it automates so much (for example, memory management), the runtime
makes the developer's experience very simple, especially when compared to
COM today. In particular, features such as reflection dramatically reduce
the amount of code a developer must write in order to turn business logic
into a reusable component.

Runtimes are nothing new for languages梫irtually every programming language
has a runtime. Visual Basic has the most obvious runtime (the aptly named
VBRUN), but Visual C++ has one (MSVCRT), as do FoxPro, JScript, Smalltalk,
Perl, Python, and Java. The .NET Framework's critical role, and what really
sets it apart, is that it provides a unified runtime and development
environment across all programming languages.

The .NET Classes
The .NET Framework's classes provide a unified, object-oriented,
hierarchical, extensible set of class libraries (APIs) for developers to
use. Today, C++ developers will use the Microsoft Foundation Classes, Java
developers will use the Windows Foundation Classes or J2EE, and Visual
Basic developers will use VB's APIs. Simply put, the .NET CLR unifies the
disparate frameworks Microsoft has today. The result is that dev-elopers no
longer have to learn multiple frameworks when working in multiple
languages. By creating a common set of APIs across all programming
languages, the .NET Framework enables cross-language inheritance, error
handling, and debugging. In effect, all programming languages, from JScript
to C++, become equals, and developers are free to choose the language they
want to use.

Here are some of the key benefits of the .NET Framework for developers:

Can use any .NET-enabled programming language. The .NET Framework enables
developers to use any .NET-enabled programming language, and it enables
applications written in these languages to integrate deeply with each
other, which means current development skills can be used right away within
the same project and future projects.

Can write less code. The .NET Framework uses a highly "componentized,"
plumbing-free design that enables developers to focus on writing business
logic. Developers don't need to write Interface Definition Language (IDL)
or Registry code anymore. ASP.NET, for example, includes dozens of controls
that encapsulate common programmer tasks, such as user validation, creating
calendars and ad rotators, and much more.

Can use XML and SOAP without learning these technologies. The .NET
Framework was built for delivering software as a service, so it is built on
XML and the SOAP family of integration standards. Simply annotate method
calls and the .NET Framework turns them into full XML Web Services. You do
not need to learn these underlying technologies because the .NET Framework
wraps classes around them.

Can run more reliable applications. The .NET Framework includes
technologies to make applications more reliable. For example, memory,
threads, and processes are managed by the .NET Framework to ensure that
memory leaks don't occur. Also, ASP.NET monitors running Web applications
and can automatically restart them at administrator-defined intervals. In
addition, when applications are upgraded (versioned), the .NET Framework
includes technologies to avoid version conflicts (often called DLL hell).

Can improve performance. The .NET Framework improves the performance of
typical Web applications. ASP.NET includes advanced compilation and caching
features that improve performance by a factor of two to three over existing
Active Server Pages applications.

Figure 2.1 gives you an overview of how the different pieces of the .NET
Framework relate to one another.

Figure 2.1. All the layers of the .NET platform, from the OS all the way up
to the highest-level classes.


The Win32 APIs are at the lowest level in this platform. Above are the
common services built in to the OS, with which you can interact. These
include the message queuing services, transactions, Internet Information
Server (IIS), and the Windows Management Instrumentation (WMI). The CLR in
the .NET Framework interacts with these lower-level services so all .NET
languages can interact with these services using a common interface. On top
of the CLR is a framework of classes, including ADO.NET and ASP.NET.

Next comes the set of languages that have been written to take advantage of
the .NET Framework. These languages are most of the common languages in use
today, including Visual Basic, C++, C# (a new language), COBOL, Perl,
Python, Eiffel, and many others.

Common Language Specification
The Common Language Specification (CLS) is a contract that states how a
language that interacts with the CLR will behave. When languages use the
CLS, they are said to be using managed code. Managed code is a set of
language constructs that all .NET languages must contain, including data
types, error handling, metadata, and so forth.

Managed code can be broken down by a compiler into a set of bytecodes,
known as the Microsoft Intermediate Language (MSIL or IL). The MSIL is
stored, along with some metadata about the program itself, in a portable
executable (EXE or DLL).

Intermediate Language
Intermediate Language (IL) is used so that a compiler can translate the
program into the final code, which can, in turn, be interpreted by the OS
and the hardware. Using IL makes it easier to create a compiler for that IL
for any OS and hardware platform.

The compiler for .NET is called a Just-In-Time (JIT) compiler. When you
distribute a DLL or EXE file, it is not in an executable format. Instead,
it is in a Microsoft IL (MSIL) format that will be compiled into native
code for the target operating system. This compilation can either be done
at runtime (JIT) or when the program is installed for the first time. In
either case, it is the JIT compiler that performs this compilation, as
shown in Figure 2.2.

Figure 2.2. Managed code is compiled down to MSIL, which is then compiled
by the JIT compiler.


Services in .NET
The .NET Framework supplies many services to a developer. Here are some of
the most notable ones:

Memory management

Threads

Garbage collection

Exception handling

Security

Application isolation

Data interaction

Encryption services

Deployment

In the past, to get all these sophisticated services, you either had to
build them yourself or use a higher-level language. The problem with
building these services yourself is they are ancillary to the actual
program. Most customers just want a business problem solved; they do not
want you spending your time developing security systems and
garbage-collection routines. In other words, they just want you to give
them a program that solves their problem. Therefore, in a low-level
language, you might end up spending twice as long to get an application
that accomplishes the business purpose because you have to spend so long on
designing all of these infrastructure services.

If you use a high-level language, most of these services are built in.
However, if they are not built in to the language, you might not be able to
build these services because the language is so far removed from the OS.
This means that it is difficult, if not impossible, to take advantage of
threading or security from that language.

All these services can be used from any language that works with the CLR.
So now your choice of language does not matter so much, because everything
compiles down to the same Intermediate Language.

Data Services (ADO.NET)
One of the new services built in to the .NET Framework is a complete new
data-access model called ADO.NET. Although it has the same name as an
earlier data-access technique, called ADO, it is very different. You might
recognize some of the objects that are similar to the Connection and
Command objects in ADO, but there are enough different methods and
properties to keep you on your toes.

The biggest difference between the two models is how the data is stored in
memory after it is read from the database. In ADO, the recordsets were
stored in a binary format. In ADO.NET, they are stored as XML. Another big
change is that ADO.NET is disconnected. That is, ADO.NET does not keep any
connections open after reading the data in from a data source.

There are several new classes, such as Command, DataAdapter, DataReader,
and DataSet. The Recordset object is gone, and all records are read either
from the DataReader or the DataSet object.

DataSet objects allow you to read in several tables into one object. You
can then set relationships between the tables in memory as well as add,
edit, and delete the data in these tables, and you can store the data back
in the database. The schema for the tables is also read in and stored in an
XML format.

ADO.NET has the capability to natively read and write to XML. In addition,
you can use OLE DB or native providers to read data from data sources such
as SQL Server, Oracle, and Access.

Security Services
Security is pervasive throughout the .NET Framework. Table 2.1 shows some
of the different types of security that you can set up for your
applications.

Table 2.1. The Different Security Types in .NET Security Type  Description 
Access Control  Secures objects, such as files, Registry keys, and
directory service objects 
Security Support Provider Interface  Establishes authenticated connections 
Logon Authenticated  Provides for password filtering, Windows logon, and
local security authentication 
Certificate Services and Components  Issues and manages certificates 
Cryptography  Provides a set of classes based on the Crypto API functions
in Windows 2000 
Smart Card  Allows you to integrate with smart card朾ased authentication 
Policy Management  Programmatically sets and manages local security
policies 


Common Type System and Standard Data Types
As part of the .NET Framework and the CLR, it is important that all
languages have access to common data types. This makes the interoperability
between languages much easier. To accomplish this, Microsoft has created
the Common Type System with a standard set of data types that each language
can utilize.

Data types in .NET are no longer defined by each language. Instead, they
are a core part of the CLR. Each data type is itself an object. Each
language has the choice to implement all of them or just a subset.

Table 2.2 lists each of the different data types and tells which languages
implement each one.

Table 2.2. Each Data Type in the .NET Framework Is Actually Implemented as
a Class Data Type  Description  Language Usage 
Byte  8-bit unsigned integer  Visual Basic: Byte

C#: Byte

Visual C++: Char

Sbyte  8-bit signed integer  Visual Basic: N/A

C#: sbyte

Visual C++: signed char

Int16  16-bit signed integer  Visual Basic: Short

C#: short

Visual C++: short

Int32  32-bit signed integer  Visual Basic: Integer

C#: int

C++: int or long

Int64  64-bit signed integer  Visual Basic: Long

C#: long

Visual C++: _int64

Unint16  16-bit unsigned integer  Visual Basic: N/A

C#: ushort

Visual C++: unsigned short

Uint32  32-bit unsigned integer  Visual Basic: N/A

C#: uint

Visual C++: unsigned int or unsigned long

Uint64  64-bit unsigned integer  Visual Basic: N/A

C#: ulong

Visual C++: unsigned __int64

Single  32-bit floating-point number  Visual Basic: Single

C#: float

Visual C++: float

Double  64-bit floating-point number  Visual Basic: Double

C#: double

Visual C++: double

Boolean  True (1) or False (0)  Visual Basic: Boolean

C#: bool

Visual C++: bool

Object  The base type of any class or data type  Visual Basic: Object

C#: object

Visual C++: Object

Char  Unicode character (16 bit)  Visual Basic: Char

C#: Char

Visual C++: __wchar_t

String  A string of Unicode characters  Visual Basic: String

C#: string

Visual C++: String

Decimal  96-bit decimal value  Visual Basic: Decimal

C#: decimal

Visual C++: Decimal