Understanding the .NET Framework - The .NET Architecture
(Page 2 of 8 )
The three primary components of the .NET architecture are the Common Language Runtime (CLR), the Common Type System (CTS), and the .NET Framework class libraries. The CLR is essentially the runtime engine that executes .NET applications; the CTS defines all of the basic data types as well as the operations that can be performed on those data types. The .NET Framework class libraries is a base set of classes grouped into Namespaces that provide access to system resources as well as standard language capabilities, such as string manipulation, I/O, and numerical functions. Figure 2-1 presents the overall architecture of the .NET Framework.
Figure 2-1. An overview of the .NET Framework architecture
In the following sections, you'll get a more detailed look into each of these core components that comprise the .NET architecture.
The Common Language Runtime
The job of the CLR is basically to load and run .NET applications. The CLR marks a big change from Microsoft's earlier methods of software development where your application glues together many separate components in order to perform various functions. In many ways, the CLR is analogous to Java's JVM (Java Virtual Machine) or to VB 6's MSVBSM.DLL in that it's a runtime layer over the operating system. However, the CLR goes beyond the capabilities of either of these by enabling cross-language integration, self-describing components, xcopy deployment, and integrated security. The CLR's most essential task is to compile .NET code into native machine instructions and execute those instructions. The code that runs in the CLR is called managed code; any code that runs outside of the CLR is referred to as unmanaged code. Managed code basically describes the situation where the CLR-not the programmer-is responsible for performing tasks such as memory allocation and exception handling.
The CLR enables a couple of key improvements over previous Microsoft development scenarios. First, the CLR enables cross-language object inheritance and exception handling, and, in addition, it provides resource management for program objects. Code that's developed using any language that targets the .NET runtime can be used to create objects that can be inherited by other languages. For example, objects that are created using C#, J#, or Managed VC++ can be seamlessly integrated into Visual Basic.NET applications. Likewise, any exceptions raised in those objects will appear exactly like native Visual Basic.NET exceptions because they all conform to the .NET error handling standards. The CLR also automatically handles memory management tasks. The CLR is responsible for allocating the memory required by an object. Further, its automatic garbage collection takes care of releasing those resources when they're no longer used-freeing the programmer from that responsibility. Cross-language integration results in more easily reusable code, and automatic resource management results in more robust programs.
When .NET programs are created, the compiler doesn't produce code that can be natively executed. Instead, the .NET compiler outputs assemblies that contain a combination of Microsoft Intermediate Language (MSIL) and metadata information. See the "Assemblies" section, later in this chapter, for more detailed information.
NOTE: The .NET Framework SDK provides both an MSIL compiler (ILasm.exe), as well as an MSIL decompiler (ILDasm.exe).
In Figure 2-2, you can see an overview of the basic process that the CLR uses for execution and assembly.
Figure 2-2. Program execution in the CLR
As Figure 2-2 illustrates, .NET source code is compiled into an assembly either using one of the command-line compilers provided by the .NET Framework SDK or by Visual Studio.NET. Much like standard unmanaged code, the files containing these assemblies typically end in the extension .exe or .dll. When the CLR executes an assembly, the class loader first parses the metadata contained in the assembly to pull out the MSIL code as well as discover any dependencies that the assembly has. Next, the CLR's Just-In-Time (JIT) compiler will compile the MSIL code into native code that can be executed on the system. However, don't think that the entire program is compiled all at once. Instead, the JIT compiles each function as it is called. Once the JIT has compiled a function, it stores the address of the compiled code, which will be directly executed for all future function calls. In addition, the .NET Framework also includes an install-time compile option that will convert the entire assembly to native code as part of the installation process.
As you might expect, there's no such thing as a free lunch, and the CLR is no exception to this axiom. Although the CLR enables a number of powerful new language capabilities, it does come at a price. The CLR is required to run .NET applications, and it doesn't come preinstalled with Windows XP or Windows 2000 Professional, or any Windows platform other than Windows 2003 Server. Instead, either the CLR must be deployed along with your .NET applications or it must be deployed prior to deploying your .NET applications. Moreover, the CLR's footprint weighs in at a hefty 20MB, making it a significant consideration, especially for client installations.
 This is chapter two of ADO.NET: The Complete Reference, by Michael and Denielle Otey (McGraw-Hill/Osborne, ISBN 0-07-222898-9, 2003). Check it out at your favorite bookstore today. Buy this book now. |
Next: The Common Type System >>
More .NET Articles
More By McGraw-Hill/Osborne
/ 28 
