Datasheet

Introducing C#
11
MSIL and JIT
When we compile code that uses the .NET Framework library, we don't immediately create operating
system-specific native code. Instead, we compile our code into Microsoft Intermediate Language
(MSIL) code. This code isn't specific to any operating system, and isn't specific to C#. Other .NET
languages – for example, Visual Basic .NET – also compile to this language as a first stage. This
compilation step is carried out by VS when we use it to develop C# applications.
Obviously, in order to execute an application more work is necessary. This is the job of a Just-In-Time
(JIT) compiler, which compiles MSIL into native code that is specific to the OS and machine
architecture being targeted. Only at this point can the OS execute the application. The "just-in-time"
part of the name here reflects the fact that MSIL code is only compiled as and when it is needed.
In the past it has often been necessary to compile your code into several applications, each of which
targets a specific operating system and CPU architecture. Often, this was a form of optimization (in
order to get code to run faster on an AMD chipset, for example), but at times it was critical (for
applications to work on both Win9x and WinNT/2000 environments, for example). This is now
unnecessary, as JIT compilers (as their name suggests) use MSIL code, which is independent of the
machine, operating system, and CPU. Several JIT compilers exist, each targeting a different
architecture, and the appropriate one will be used to create the native code required.
The beauty of all this is that it requires a lot less work on our part – in fact we can just forget about
system-dependent details, and concentrate on the more interesting functionality of our code.
Assemblies
When we compile an application, the MSIL code created is stored in an assembly. Assemblies include
both executable application files that we can run directly from Windows without the need for any other
programs (these have a .exe file extension), and libraries for use by other applications (which have a
.dll extension).
As well as containing MSIL, assemblies also contain meta information (that is, information about the
information contained in the assembly, also known as metadata) and optional resources (additional data
used by the MSIL, such as sound files and pictures). The meta information allows assemblies to be fully
self-descriptive. We need no other information in order to use an assembly, meaning that we avoid
situations such as failing to add required data to the system registry and so on, which was often a
problem when developing using other platforms.
This means that deploying applications is often as simple as copying the files into a directory on a
remote computer. Since no additional information is required on the target systems, we can just run an
executable file from this directory and (assuming the .NET CLR is installed) away we go.
Of course, we won't necessarily want to include everything required to run an application in one place.
We might write some code that performs tasks required by multiple applications. In situations like this,
it is often useful to place this reusable code in a place accessible to all applications. In the .NET
Framework, this is the Global Assembly Cache (GAC). Placing code in this cache is simple – we just
place the assembly containing the code in the directory containing this cache.