Non-standardized namespaces: 

• System.CodeDom
• System.ComponentModel
• System.Configuration
• System.Data
• System.Deployment
• System.DirectoryServices
• System.Drawing
• System.EnterpriseServices
• System.Linq
• System.Linq.Expressions
• System.Management
• System.Media
• System.Messaging
• System.Resources
• System.ServiceProcess
• System.Timers
• System.Transactions
• System.Web
• System.Windows.Forms

CIL (Common Intermediate Language) and IL

Old programming languages like C++ generate instructions (Mostly called machine codes) that a processor can interpret directly. In contrast, modern platforms Like Java and CLI compiler generate instructions in CIL language (In Java, BYTECODE). .NET codes are compiled into IL (Microsoft CIL implementation; also called MSIL), and IL is what the CLI processes. In essence, IL is the CLI’s assembly language and in fact, it looks similar to assembly. It’s called IL (Intermediate Language) because it acts as intermediate step between.NET language codes and a specific platform. During execution time, the IL converts to machine code which current running processor can understand. Different processors can understand different types of machine codes instructions. However, this conversion to machine code is still not adequate for code execution.

Languages that compile to the CIL are source languages and each has a custom compiler that converts the source language to the CIL. Once codes compiled to the CIL, the origin source language doesn't matter. This powerful feature enables the development of libraries by different development groups, without concern for the language choice of a particular group. Thus, the CIL enables programming language interoperability as well as platform portability.

VES (Virtual Execution System) or Runtime 

VES (Virtual Execution System) or Runtime is an agent which .NET Languages compilation is dependent to it. The Runtime is able to understand CIL statements and compile them to machine code. This agent is responsible for .NET programs execution management and provides additional services (Garbage Collection, OS Security, Code Security…). Most CLI implementations prefer CIL “execution-time compilation”. As a result, they compile CIL codes to machine code in run-time. Nonetheless the time which compilation must occur hasn't specified by the CLI. In fact, the CLI even allows the CIL to be interpreted rather than compiled (Similar to scripting languages) or even get compiled to machine code immediately instead of translated to CIL. Maintaining the control of the program, this agent (VES) keeps running even after compilation of the CIL code to machine code.

Managed code is the code that executes under the agent control. Managed execution is the process of executing under control of the “Runtime” (VES). In fact, memory for the data is automatically allocated and de-allocated by the runtime. This process generally called “Garbage Collection” and occurs by VES.

NGEN (Native Image Generator)

There is a .NET tool called NGEN which allows compilation to machine code before running the program. It can be considered as pre-execution time compilation (like C++) and needs to take place on the computer on which the program will be executing. It is because it will evaluate the machine characteristics (processor, memory, platform, and so on) in order to generate more efficient code. Its advantage is that it can reduce the need for the jitter to run at startup and by this, it reduce the startup time. However, it causes the compiled output to become dependent to the machine which it runs. 

JIT (Just-In-Time) Compiler

JIT Compiler is a component inside the “runtime” which performs compilation. JITTING can occur when the program is installed or executed. The CLI is not an interpreter. Unlike interpreters, it doesn't re-translate the IL code each time it executes. Generally, interpreters aren’t efficient run-time platforms. The process of compiling IL code into machine code takes some time, but for each part of a program, it generally means only one-time compile per process. Once the code is compiled, the CLI holds it and executes the compiled version the next time it’s needed. It is just as quickly as traditionally compiled code.

Since JIT compilation phase adds some complexity, it has initial run time performance reduction. In fact, by putting the benefits of a JIT compiling structure and the CLI into account, the time penalty of JIT compiling can be ignored. Managed applications which have made by CLI are more efficient than native compiled applications because of the following:

• IL code can consume less memory: Their working set is normally smaller than native applications. Working set is the number of memory pages applications consume. Keep in mind that to measure the required work time for doing a job, the time for management structures, assembly metadata, and other constructs must calculated which has done automatically by CLI. Thus, if you spend same amount of time for doing a job which has same features, the amount of required work of native applications will be much more than managed applications. However, for very small applications, managed code along with the CLI can consume more memory than the native one.
• Only executed code is getting compiled: IL code is generally more compact than machine code. In fact, minimizing the compiled code reduces the memory footprint of the application.
• JIT-compiled code is highly optimized: Code of compiled native applications is optimized based on generalizations like the typical computer system topology. In contrast, JIT compiled code is optimized based on the current platform which it runs. Therefore, it is very specific optimization and often generates far more performant code than statically compiled native applications.
• CLI may perform run time optimizations: In native applications, you define the optimizations at compile time. But, because compilation occurs at run time in the CLI, it can apply optimizations at any time. For code that it getting called frequently, it could recompile with more optimizations so it executes faster. The CLI efficiency can be different depending on how many CPUs are on the target platform or even what architecture family the CPUs belong to. In contrast, for native applications, you have to do more manual work at both run time or compile time.
• CLI intelligent compilation control: If the CLI determines that some parts of code are placed in different locations bit they call each other frequently, it has the liberty to move them in memory so that they will be placed within the same group of memory pages and thus, it minimizes the number of page faults and increasing the required cache when runs application. In fact, in the native application case optimization is based on guesses and assumptions whereas in the CLI case, the optimizations are based on real data for the exact platform. 

Assemblies

According to CLI specification, assembly is the CIL output after code’s compilation. Assemblies can be library assemblies (DLL – Class Libraries) or process assemblies (EXE - Executables). An assembly can reference other assemblies and files such as resource files that have been localized. This is an important specification modern programming platforms have, because it significantly improves maintainability and allows a single component to be shared across multiple programs.

An assembly can consist of one or more files. Code files are called modules. Although Visual Studio does not support using different languages in one assembly, technically an assembly can contain more than one code module which has used several different languages.

Assemblies form the logical construct of a component or unit of deployment. Although an assembly can include multiple files, there is only one version number for the entire group of files and it is placed in the main assembly manifest. If you change any of the referenced files without updating the assembly manifest, you will break the manifest and the assembly’s validity.  Microsoft has provided “ILMerge.exe” utility for combining multiple modules and their manifests into a single file assembly.

Assemblies can consist of multiple files. These files can include compiled modules, resources, and any other components listed in the assembly manifest. The assembly manifest is typically included in the main assembly module and contains essential identification information, including which pieces belong to the assembly. By using this information, the assembly loader can determine, among other things, if an assembly is incomplete or has been tampered with.

Assemblies are either strongly named or not strongly named. A strongly named assembly has a hash code built into its manifest that the loader can use to test the integrity of the assembly to ensure it has not been modified. Assemblies can also be digitally signed in order to identify their producer. 

All header information about a library and its dependencies is in a portion of the metadata known as the manifest. Assembly manifest is a text file which contains assembly’s metadata. It describes the relationship and dependencies of the assembly’s components and the types it defines and imports. It also expresses versioning information, scope information and security permissions required for it. It can be considered as assembly’s header. The manifest information embedded within an assembly can be viewed using IL Disassembler (ILDASM.exe). The manifest includes a reference to all the files an assembly depends on. As a result, it can be used to determine an assembly’s dependencies.

During execution of the assembly, the runtime needs to examine only the manifest to determine what files it requires. Unlike Microsoft’s COM files of the past, CLI assemblies rarely require any type of registration. Instead, it is possible to deploy applications by copying all the files that a program requires into a particular directory, and then executing it. Because of this, CLI applications deployment often referred to “xcopy” for its easy deployment process. 

Visual Studio .NET doesn't support integrated tools for building multi-module assemblies, and when they use such assemblies, IntelliSense does not fully function. Multi-module assemblies not only facilitate breaking a program into components, but it also allows the multiple source languages development. Figure below illustrated a “Multiple Assembly”:

Metadata 

It refers to types and files included (embedded) in a program. Metadata attachment to the assembly files happens during execution the IL instructions. It also describes all classes and their members that are defined within it or will call from outside of assembly. A method’s metadata contains its description, including the class and its assembly, the return type and all of its parameters.

When the run-time executes IL it will check to make sure that the metadata of the called method is the same as the metadata that is stored in the calling method. This ensures that a method can only be called with exactly the right number of parameters and exactly the right parameter types.

Metadata provides a mechanism for the runtime to handle a mixture of native and managed code execution. Also, it increases code and execution robustness because it makes it easier to migrate from one library version to another and it replaces compile-time-defined binding with load-time implementation.

The metadata also contains custom attributes that may change the code structure. Attributes provide additional metadata about CIL instructions of the program at execution time. Metadata is available at execution time by a mechanism known as reflection. 

Garbage Collection 

It is the process of automatically de-allocating memory based on the program’s needs. This is a significant programming problem for languages because without the garbage collector, programmers must remember to always free any memory allocations they make. Forgetting to do so, or doing so repeatedly for the same memory allocation, results memory leaks or corruption into the program.

Garbage collection is obviously a core function of the runtime. Its purpose is to restore memory consumed by objects that are no longer referenced. The emphasis in this statement lies with memory and references. The garbage collector is only responsible for restoring memory; it does not handle other resources such as database connections, handles (files, windows, and so on), network ports, and hardware devices such as serial ports. Also, the garbage collector determines what to clean up based on whether any references remain. This means that the garbage collector works with reference objects and restores heap’s memory only. In addition, maintaining a reference to an object will delay the garbage collector from reusing the memory consumed by the object. 

References

1. Galli, P., 2009. The ECMA C# and CLI Standards. [Online] Available at: http://blogs.technet.com/b/port25/archive/2009/07/06/the-ecma-c-and-cli-standards.aspx [Accessed 12 7 2012]. 
2. Griffiths, I., Adams, M. & Liberty, J., 2010. Programming C# 4.0. 6th ed. Sebastopol, CA: O’Reilly.
3. MSDN, 2012. Assembly Manifest. [Online] Available at: http://msdn.microsoft.com/en-us/library/1w45z383.aspx  [Accessed 2 9 2012]. 
4. Nagel, C. et al., 2010. Professional C# 4 and .NET 4. Indianapolis, Indiana: Wiley.
5. Nash, T., 2010. Accelerated C# 2010. 1st ed. New York: Apress.
6. Troelsen, A., 2010. Pro C# 2010 and the .NET 4 Platform. 5th ed. New York: Apress. 

Points of Interest 

As far as I realized, it's not easy to find a simple succinct explanation about the .Net architecture in the Web. I believe it is useful for every .Net developer (regardless of their level of experts) to know the fundamental structure of .Net framework. In addition, it is good to know some features about .Net in order to understand the advantages of .Net as a platform. I, personally learned many new features and specifications of .Net by doing this research. I have to emphasize that this article which I compiled is mostly a research based article. It based on my experience and the resources which I looked in order to elicit comprehensible easy-to-understand information for each part. I'll try to add more information when I learned. 

History  

1.0 - 9/29/2012: The first publish of the article.