Runtime resolves Type References

public static void Main() {

System.Console.WriteLine("Hi");

}

The above code is compiled and built into an assembly, say Program.exe. When you run this application, the CLR loads and initializes. Then CLR reads the assembly’s CLR header, looking for the MethodDefToken that identifies the application’s entry point method (Main). From the MethodDef metadata table, the offset within the file for the method’s IL code is located and JIT-compiled into native code, which includes having the code verified for type safety. The native code then starts executing. ILDasm.exe contains the attached left side images.

When JIT-compiling this code, the CLR detects all references to types and members and loads their defining assemblies (if not already loaded). As you can see, the IL code above has a reference to System.Console.WriteLine. Specifically, the IL call instruction references metadata token 0A000003. This token identifies entry 3 in the MemberRef metadata table (table 0A). The CLR looks up this MemberRef entry and sees that one of its fields refers to an entry in a TypeRef table (the System.Console type). From the TypeRef entry, the CLR is directed to an AssemblyRef entry: “mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089”. At this point, the CLR knows which assembly it needs.

Now the CLR must locate the assembly in order to load it. When resolving a referenced type, the CLR can find the type in one of three places:

1. Same file: Access to a type that is in the same file is determined at compile time (sometimes referred to as early bound). The type is loaded out of the file directly, and execution continues.
2. Different file same assembly: The runtime ensures that the file being referenced is in the assembly’s FileRef table of the current assembly’s manifest. The runtime then looks in the directory where the assembly’s manifest file was loaded. The file is loaded, its hash value is checked to ensure the file’s integrity, the type’s member is found, and execution continues.
3. Different file, different assembly: When a referenced type is in a different assembly’s file, the runtime loads the file that contains the referenced assembly’s manifest. If this file doesn’t contain the type, the appropriate file is loaded. The type’s member is found, and execution continues.

GacUtil

If an assembly is to be accessed by multiple applications, the assembly must be placed into a well-known directory, and the CLR must know to look in this directory automatically when a reference to the assembly is detected. This well-known location is called the global assembly cache (GAC), which can usually be found in c:\windows\assembly directory

The GAC directory is structured: It contains many subdirectories, and an algorithm is used to generate the names of these subdirectories. You should never manually copy assembly files into the GAC; instead, you should use tools to accomplish this task. These tools know the GAC’s internal structure and how to generate the proper subdirectory names. While developing and testing, the most common tool for installing a strongly named assembly into the GAC is GACUtil.exe.

you can invoke GACUtil.exe, specifying the /i switch to install an assembly into the GAC, and you can use GACUtil.exe’s /u switch to uninstall an assembly from the GAC. Note that you can’t ever place a weakly named assembly into the GAC. If you pass the file name of a weakly named assembly to GACUtil.exe, it displays the following error message: “Failure adding assembly to the cache: Attempt to install an assembly without a strong name.”

Deployment Modes

There are two kinds of deployment in .NET framework.

They are (1) private deployment, in which assemblies are placed in the application’s base directory (or a subdirectory thereof) for the application’s sole use. Deploying assemblies privately gives a company a large degree of control over the naming, versioning, and behavior of the assembly.

(2) global deployment, in which assemblies can be accessed by multiple applications. The assemblies that ship with the Microsoft .NET Framework are an excellent example of globally deployed assemblies, because all managed applications use types defined by Microsoft in the .NET Framework Class Library (FCL).

Key differences are listed as: A private deployment is available to a particular applications where they are kept. And cannot be references outside the scope of the folder where they are kept. In contrast, global deployment are accessible globally/shared across the machine to all the applications. For using those assemblies you need to register the assembly with a strong name in the global assembly cache(GAC) using gacutil.exe. GAC can be found on all the computers with .Net framework installed. Therez an alternative without GAC and the solution is published at http://devcity.net/Articles/254/1/article.aspx. Based on the business need, you can choose the deployment mode.

Assembly Linker

Assembly Linker is useful if you want to create an assembly consisting of modules built from different compilers (if your compiler doesn’t support the equivalent of C#’s /addmodule switch) or perhaps if you just don’t know your assembly packaging requirements at build time. You can also use AL.exe to build resource-only assemblies, called satellite assemblies, which are typically used for localization purposes. This utility can produce an EXE or a DLL PE file that contains only a manifest describing the types in other modules. Letz see an illustration.

al /out:FullName.dll /t:library FirstName.netmodule LastName.netmodule

In this example, two separate modules, FirstName.netmodule and LastName.netmodule, are created. Neither module is an assembly because they don’t contain manifest metadata tables. Then a third file is produced: FullName.dll, which is a small DLL PE file (because of the /t[arget]:library switch) that contains no IL code but has manifest metadata tables indicating that FirstName.netmodule and LastName.netmodule are part of the assembly. The resulting assembly consists of three files: FullName.dll, FirstName.netmodule and LastName.netmodule.

Happy New Year 2011 with happy learning.