The .NET Framework
The .NET Framework is a high-productivity, standards-based, multilanguage application execution environment. It consists of a runtime environment called the common language runtime and a set of libraries to boost programmers' productivity.
Common Language Runtime
The common language runtime, or just the runtime, is Microsoft's implementation of the ECMA CLI specification. When a .NET application is run, the common language runtime manages the loading and execution of the code and provides many runtime services to the application.
If you have been developing your code under COM, you will be surprised by the simplicity the .NET model offers. Forget dealing with GUIDs, CLSIDs, PROGIDs, IDL, type-libraries, apartments, server registration, AddRef(), Release(), and so on. They all have been replaced by a simpler model of programming.
It would not be fair to say that COM is dead. The basic tenet of COM, the ability for applications to communicate across hardware and programming language boundaries, is still present in .NET. In particular, the first release of the .NET Framework still depends on COM+ to provide enterprise services such as transaction and queuing. However, the COM infrastructure has certainly been replaced under .NET.
Besides providing a simpler model of communication, the .NET runtime provides many other services to simplify programming and to develop robust and secure applications. Any code that targets the .NET runtime is called the managed codeit can take advantage of the services offered by the .NET runtime. All other code, including existing legacy code, is called the unmanaged code. Although, the common language runtime can execute the unmanaged code, the code cannot avail the services provided by the common language runtime.
Let's examine some services provided by the common language runtime.
In the simplest case, the directory hierarchy of an application can be copied to a machine and the application can be executed. There is no need to modify any registry entry. This is referred to as XCOPY deployment.
The framework also solves the "DLL hell" problem. A common problem with Windows is that upgrading a dynamic-link library (DLL) routinely breaks an already installed application. Under .NET, two versions of an application can execute side-by-side without breaking any application.
When a .NET application is built, the code is stored in a language called Microsoft Intermediate Language (MSIL). When the application is executed, the runtime performs a just-in-time (JIT) compilation to convert the MSIL code to machine instructions. This makes a .NET application run on any CPU type, as long as a JIT compiler is available for the CPU. Moreover, the JIT compiler can perform hardware-specific optimizations, boosting execution performance.
Automatic Memory Management
When writing managed code, developers need not worry about memory deallocation issues. The runtime automatically frees any unused memory using a mechanism called garbage collection. Not only does this simplify programming, but it also makes the application more robust; as programmers sometimes simply forget to free previously allocated memory.
The .NET Framework defines a specification called the Common Language Specification (CLS). Among other things, the CLS defines a set of data types that is intended to work across all .NET-compliant programming languages. If these data types are used, the runtime provides seamless integration between applications developed in different programming languages. The integration is so seamless that a type defined in one language can be inherited in another language. Even exceptions can be thrown from one language and caught in another language.
An application developed for .NET contains complete information about the types it implements, the methods each type defines, the parameters for each method, and so on. The presence of such metadata eliminates the need for COM-style IDL and type libraries. This also makes it possible to keep the Windows registry clean.
.NET defines a permission-based security model that offers fine-grained control over which assembly can access what resource on the local machine. The security becomes especially important when users access code over the Internet. The runtime prevents the executions of any unauthorized code.
The runtime provides the functionality to integrate with legacy COM servers. The runtime also provides the ability to invoke any unmanaged code or Windows APIs (although such an application may not be portable to other platforms).
The .NET Framework also provides hundreds of types (classes, interfaces, structures, etc.) that not only enable programmatic access to the features of the common language runtime, but also provide a number of useful high-level services to help developers boost their productivity. These types are collectively referred to as the .NET Framework Class Library.
The .NET Framework Class Library can roughly be broken down into four groupsthe Base Class Library (BCL), ADO.NET and XML, Windows Forms, and ASP.NET.
The BCL implements the set of functionality that is shared by all the applications targeting the .NET Framework. It defines and implements all the core data types (e.g., string, integer, float, etc.) used by every application.
ADO.NET is the successor to an earlier data access technology called Active Data Object (ADO). ADO.NET provides a set of classes to access and manipulate data. The data is typically obtained from a database and can be converted to XML for better remote manipulation.
Windows Forms (often called WinForms) provide features for developing standard Windows desktop applications. They provide a rich, unified set of controls and drawing functions for all languages, effectively wrapping Windows user interface (UI) APIs in such a way that developers rarely would need to access the Windows APIs directly.
ASP.NET is the successor to a Web-request processing technology called Active Server Pages (ASP). ASP.NET adds two significant enhancements to ASP:
It simplifies the process of developing Web services.
It provides a model of developing a Web browser-based UI called Web Forms. Controls on the Web Forms run on the server but the UI is displayed on the client browser. This takes lots of coordination and behind-the-scenes activity. However, the end result is Web interfaces that look and behave very much like WinForms interfaces. Moreover, the Web interfaces can deal with a broad range of browsers such as Microsoft Internet Explorer as well as less capable browsers such as the ones found on wireless palmtop devices. WebForms will render themselves appropriately on the target device.