LogoASPAlliance: Articles, reviews, and samples for .NET Developers
Miscellaneous Concepts of .NET – Part 2
by Uday Denduluri
Average Rating: This article has not yet been rated.
Views (Total / Last 10 Days): 48866/ 140


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.


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.

ngen <action> [options]

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


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.”


In this article you have learned the basics of JIT compilation and GAC in detail.

Product Spotlight
Product Spotlight 

©Copyright 1998-2021  |  Page Processed at 2021-12-08 11:29:29 PM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search