Introduction to the .NET runtime

Discussion of this entity in the .NET environment.


.NET Developer Tip

Introduction to the .NET runtime
Kevin Burton

One of the changes in .NET is the use of the runtime module, which is used by executables to accomplish tasks. This tip, excerpted from InformIT, discusses this entity. The tip comes from a chapter of .NET Common Language Runtime Unleashed, by Kevin Burton, published by Sams.


Before .NET, an executable (usually a file with an .exe suffix), was the application. In other words, the application was contained within one file. To make the overall system run more efficiently, the application would elect to use code that was shared (usually a file with a .dll suffix). If the program elected to use shared code, you could either use an import library (a file that points function references to the DLL that is associated with the import library), or you could load the DLL explicitly at runtime (using LoadLibrary, LoadLibraryEx, and GetProcAddress). With .NET, the unit of execution and deployment is the assembly. Execution usually begins with an assembly that has an .exe suffix. The application can use shared code by importing the assembly that contains the shared code with an explicit reference. (You can add the reference via the "Add References" node in Visual Studio .NET or include it via a command-line switch /r). The application can also explicitly load an assembly with Assembly.Load or Assembly.LoadFrom.

Before going further, you need to learn definitions of some of the terms:

  • Assembly -- The assembly is the primary unit of deployment within the .NET Framework. Within the base class libraries is a class that encapsulates a physical assembly appropriately named Assembly. When this book refers to the class or an instance of the class, it will be denoted as Assembly. This class exists in the System namespace. An assembly can contain references to other assemblies and modules. Chapter 4, "The Assembly," contains more detailed information about assemblies.
  • Module -- A module is a single file that contains executable content. An assembly can encapsulate one or more modules; a module does not stand alone without an assembly referring to it. Similar to assembly, a class exists in the base class library that encapsulates most of the features of a module called Module. When this book refers to Module, it is referring to the class in the base class library. This class exists in the System namespace.
  • AppDomain -- An application domain has been referred to as a lightweight process. Before .NET, isolation was achieved through separate processes through assistance from the OS and the supporting hardware. If one process ran amok, then it would not bring down the whole system, just that process. Because types are so tightly controlled with the .NET Framework, it is possible to have a mechanism whereby this same level of isolation can occur within a process. This mechanism is called the application domain, or AppDomain. As with modules and assemblies, a class in the base class library encapsulates many of the features and functionality of an application domain called AppDomain. This class exists in the System namespace. When this book refers to the class, it will be called AppDomain.
  • IL or MSIL -- IL stands for Intermediate Language, and MSIL stands for Microsoft Intermediate Language. IL is the language in which assemblies are written. It is a set of instructions that represent the code of the application. It is intermediate because it is not turned in to native code until needed. When the code that describes a method is required to run, it is compiled into native code with the JIT compiler. Chapter 5 contains information about individual IL instructions.
  • JIT -- JIT stands for Just-In-Time. This term refers to the compiler that is run against IL code on an as-needed basis.

After the code is "loaded," execution of the code can begin. This is where the old (pre-.NET) and the new (.NET) start to diverge significantly. In the case of unmanaged code, the compiler and linker have already turned the source into native instructions, so those instructions can begin to execute immediately. Of course, this means that you will have to compile a separate version of the code for every different native environment. In some cases, because it is undesirable to ship and maintain a separate version for every possible native environment, only a compatible version is compiled and shipped. This leads to a lowest common denominator approach as companies want to ship software that can be run on as wide a range of environments as possible. Currently, few companies ship programs that target environments that have an accelerated graphics engine. Not only would the manufacturer need to ship a different program for each graphics accelerator card, but a different program also would need to be developed for those cases where a graphics accelerator was lacking. Other examples of hardware environments in which specific optimizations could be taken advantage of would be disk cache, memory cache, high-speed networks, multiple CPUs, specialized hardware for processing images, accelerated math functions, and so forth. In numerous other examples, compiling a program ahead of time either results in a highly optimized yet very specific program, or an unoptimized and general program.

One of the first steps that the CLR takes in running a program is checking the method that is about to be run to see whether it has been turned into native code. If the method has not been turned into native code, then the code in the method is Just-In-Time compiled (JITd). Delaying the compilation of a method yields two immediate benefits. First, it is possible for a company to ship one version of the software and have the CLR on the CPU where the program is installed take care of the specific optimizations that are appropriate for the hardware environment. Second, it is possible for the JIT compiler to take advantage of specific optimizations that allow the program to run more quickly than a general-purpose, unmanaged version of the program. Systems built with a 64-bit processor will have a "compatibility" mode that allows 32-bit programs to run unmodified on the 64-bit CPU. This compatibility mode will not result in the most efficient or fastest possible throughput, however. If an application is compiled into IL, it can take advantage of the 64-bit processing as long as a JIT engine can target the new 64-bit processor.

The process of loading a method and compiling it if necessary is repeated until either all of the methods in the application have been compiled or the application terminates. The rest of this chapter explores the environment in which the CLR encloses each class method.


To read this entire tip, click over to InformIT. You have to register there, but the registration is free.

For More Information


This was first published in May 2002
This Content Component encountered an error

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide

SearchWinDevelopment

Close