|
Miscellaneous Concepts of .NET – Part 2
|
by Uday Denduluri
Feedback
|
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days):
48538/
74
|
|
|
Introduction |
In this article we will discuss some miscellaneous concepts
of .Net technology. This article will be the continuation for my previous article. We will discuss Just in
Time compilation in detail in the first part of my article and then discuss the
GAC and satellite assemblies.
|
What is JIT Compilation? |
Before we understand Just in Time compilation let us get an
overview of compilation of source code to Microsoft Intermediate Language
(MSIL). MSIL is the CPU independent instructions. MSIL is generated from the
source code written in any .NET compliant language. The respective compiler is
responsible for translating the source code to the MSIL. The same is shown in figure
1. MSIL includes instructions for loading, storing, initializing, and calling
methods on objects, as well as instructions for arithmetic and logical
operations, control flow, direct memory access, exception handling, and other
operations. When a compiler produces MSIL, it also produces metadata. The MSIL
and metadata are contained in a Portable Executable (PE) file that is based on
and extends the published Microsoft PE and Common Object File Format (COFF)
used historically for executable content. This file format, which accommodates
MSIL or native code as well as metadata, enables the operating system to
recognize common language runtime images.
Figure 1
A native code is the code which CPU can execute. MSIL should
be converted to the native code to make the code executable. This will be done
by the .NET runtime Just In Time Compiler. Because the common language runtime
supplies a JIT compiler for all the supported CPU architectures, developers can
write a set of MSIL that can be JIT compiled and run on computers with
different architectures. However, the managed code will run only on a specific
operating system if it calls platform-specific native APIs or a
platform-specific class library.
Figure 2
The JIT compilation has some different flavors based on the
compilation procedures and verification process while compilations.
·
Compilation Mode
·
Verification process
|
Compilation Mode |
Let us discuss the Compilation mode in detail. We have two
variants of compilation mode, normal mode and Install time code Generation. Let
us illustrate the differences between both. This will give us a better
understanding on these compilation concepts.
Standard JIT Compilation option
|
Install Time Code Generation
|
Does not convert all the MSIL into native code.
|
Converts all the MSIL into native code in a single shot.
|
Converts the MSIL to native code during execution time and
stores the native code so that it should be accessible.
|
The entire assembly is converted into native code at the
installation time only. Of course it takes care of the other assemblies
referred in this assembly.
|
Loading and staring of the application is a bit slow with
this option.
|
Loading and starting the application is much quicker when
compared with standard JIT compilation option.
|
|
Verification Process of JIT Compilation |
As a part of JIT compilation the verification process is
defined as the process to verify if the code is Type safe. This means that it
only accesses the memory locations it is authorized to access. Code that is
proven during verification to be type-safe is called verifiably type-safe code.
Code can be type-safe, yet not be verifiably type-safe due to the limitations
of the verification process or of the compiler. For some languages like Visual
C++ the type safe managed code is not available. We can call this as type safe
code and not verifiably type safe code.
These are the some of the verifications that are checked for
during the verification process:
·
A reference to a type is strictly compatible with the type being
referenced.
·
Only appropriately defined operations are invoked on an object.
·
Identities are what they claim to be.
|
NGEN Tool |
The Native Image Generator (Ngen.exe) is a tool that creates
native images, which are files containing compiled processor-specific machine
code, and installs them into the native image cache on the local computer. This
is an alternative to the JIT compiler. There are lots of changes to NGEN with
.NET Framework 2.0.
·
Installing an assembly also installs its dependencies,
simplifying the syntax of Ngen.exe.
·
Native images can now be shared across application domains.
·
New action, update, re-creates images that have been invalidated.
·
Actions can be deferred for execution by a service that uses idle
time on the computer to generate and install images.
·
Some causes of image invalidation have been eliminated.
|
Using NGEN Tool |
Native Image Generator can be used by calling this command
from the command prompt.
We have different actions defined for the NGEN tool. Let us
see each of them.
·
Install – Generates the native images for an assembly and its
dependencies and installs the images in the native image cache.
·
Uninstall - Deletes the native images of an assembly and its
dependencies from the native image cache.
·
Update - Updates native images that have become invalid.
·
Display - Displays the state of the native images for an assembly
and its dependencies.
·
ExecuteQueuedItems - Executes queued compilation jobs.
·
Queue - Pauses the native image service, allows the paused
service to continue, or queries the status of the service.
|
What is GAC? |
The Global assembly cache (GAC) stores assemblies
specifically designated to be shared by several applications on the computer.
Assemblies deployed in the global assembly cache must have a strong name. When
an assembly is added to the global assembly cache, integrity checks are
performed on all files that make up the assembly. GAC physically creates
directories for each version of assembly. The Global Assembly Cache (GAC), when
viewed using Explorer, has its view rendered in a special manner by the OS
shell. When an Assembly is added to GAC these are the attributes that it takes.
·
Assembly Name – Name of the Assembly
·
Version – Version [Major-Minor-Revision-Build]
·
Culture – Culture will be null for normal Assembly
·
Public Key Token - This is a 64-bit hash of the public key which makes the assembly name unique
·
Processor Architecture – Either MSIL or x86
|
What are SatelliteAssemblies? |
|
Satellite Assemblies in GAC |
We can have satellite assemblies installed in GAC. The steps
for installing the satellite assemblies are as follows.
Creating a Satellite Assembly from resource file – The
Listing 1 creates a satellite assembly of the name Applicatio.Resources.dll
from the abcd.en.resources file. Listing 1 will run in the command prompt.
Listing 1
al /t:lib /embed:abcd.en.resources /culture:en /out:Application.resources.dll
Attach a strong name to the Satellite Assembly by Delay
signing the Assembly.
Listing 2
sn –k ApplicationKey.snk
sn –p ApplicationKey.snk PublicKey.snk
al /t:lib /embed:abcd.en.resources /culture:en /out:Application.resources.dll /delay+ /keyfile:PublicKey.snk
Resign an Assembly.
Listing 3
sn –R Application.resources.dll ApplicationKey.snk
Install a Satellite Assembly in GAC.
Listing 4
gacutil /i:MyApp.resources.dll
|
Advantages of Having a Satellite Assembly in GAC |
Let us imagine we have some loosely coupled components as a
part of our application. It is up to the user to plug and unplug the
components. In such a scenario if we want out component to be localizable,
making the satellite assembly will be the only option. In this scenario the
main application would expose an interface to get the current culture. Based on
the current culture, all the components will apply the culture.
Figure 3 shows the architecture where a loosely coupled
component is also globalized. As shown in Figure 3 the Main application exposes
an interface to get the current culture. The current culture will be read by
the loosely coupled components and will be applied. As the satellite assemblies
are already installed in Global Assembly Cache (GAC), the .NET runtime will
search for the same and get back the desired culture assembly.
Figure 3
|
Conclusion |
JIT compiler is responsible for converting MSIL code to
native code. There are different modes for compiling the MSIL to native code.
These are standard JIT option and Install time code generation. Each one is
explained with discussing the advantages and disadvantages. NGEN tool is a tool
that creates native images containing the compiler processor-specific code.
There are different actions of NGEN tool like installing, uninstalling, etc.
Global Assembly Cache (GAC) is the global system level
repository where all the assemblies can be installed. To install an Assembly it
has to be strong named. Satellite Assemblies are assemblies with resource
specific to a particular culture. The satellite assemblies can also be put into
GAC. This is possible as GAC has an attribute called “culture.”
|
References |
|
Summary |
In this article you have learned the basics of JIT
compilation and GAC in detail.
|
|
|
|
Product Spotlight
|
|