Overview of the .NET Framework


ASP.NET Developer's JumpStart
By Paul D. Sheriff, Ken Getz
Table of Contents
Chapter 2.  Introduction to Microsoft .NET

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 virtually 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 based 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


    ASP. NET Developer's JumpStart
    ASP.NET Developers JumpStart
    ISBN: 0672323575
    EAN: 2147483647
    Year: 2002
    Pages: 234

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net