.NET Framework CLR: Common Language Runtime

April 17, 2013 by

Ajay Yadav

Introduction

The point of this article is to lay down the conceptual groundwork of numerous .NET related topics such as CLR, CTS, CLS, Managed Code, JIT Compilation, Security, Assemblies and Reflection. You will also understand the relationship between various aspect of .NET framework, such as Common Type System (CTS) and the Common Language Specification (CLS). This article discusses the advantage of the .NET framework and managed code. Here you will also overview the language-agnostic and platform-independent nature of the .NET framework.

Learn Digital Forensics

Build your skills with hands-on forensics training for computers, mobile devices, networks and more.

Start Learning

.NET Overview

The .NET Framework is a rare software platform for building systems on the Windows family of operating systems such as Window 7, 8, 2003, 2008 server as well as on non-Microsoft operating systems such as Linux, FedoraFedora, and Mac. The .NET framework is the set of platform libraries and components that constitute .NET API. The .NET framework is factored into several components such as CLR (Virtual Machine)-that is responsible for executing managed code.

The .NET framework is an amazing convergence of many technologies such as C#,MSIL,ASP.NET, XML, ADO.NET,COM+, DCOM, VC++, Active-X, WCF, WPF, etc. We can build rich user interface desktop applications, web applications ,web services and distributed applications using the .NET framework. Here is a glimpse of some core features provided courtesy of .NET:

What is Common Language Runtime?

Common Language Runtime is the backbone of the .NET framework. CLR takes care of a number of low-level executions such as application hosting, thread handling, memory management, security checks and application performance. Its primary role is to locate, load, and manage the .NET types (class, array, object etc.). The term service refers to as a collection of services that are required to execute a code. The beauty of CLR is that all .NET-supported languages can be executed under this single defined runtime layer. The spinal cord of CLR is represented by a library refers to as mscoree.dll (common object runtime execution engine). When an assembly is referenced for use, mscoree.dll is automatically loaded.

The CLR first locates the referenced assembly, and then it loads it into memory, compiles the associated IL code into platform specific instructions, performs security related checks, and finally executes the code.

In Depth, the .NET compilation process completes in two stages; first, the C# code you write is compiled into an Intermediate Code (MSIL). All .NET languages are compiled into virtual identical IL code. The compiled file with IL code is referred to as Assembly.

[caption id="attachment_18402" align="alignnone" width="601"] Managed Code[/caption]

The second level of compilation happens just before the application is executed. At this point, the IL code is compiled into low-level native machine code. This stage is known-as Just-In-Time (JIT) Compilation. Finally .NET CLR produces the executable or library files and executes the code.

Managed Code

Code developed and running under the control of the CLR is often termed managed code

Microsoft shared the idea of IL code from Java byte code in which IL code can be quickly translated into native machine code. In other words, by compiling to IL code, you obtain platform independence for .NET in much same way as compiling java code.

IL code is compiled (JIT compilation), whereas java byte code was interpreted. One of the advantages of java was that, on execution, the process of translating from java byte code to native executable resulted in loss of performance. Instead of compiling the entire applications in one go; the JIT compiler simply compiles each portion of code. This is why we can expect that execution of managed IL code will be as fast as executing native code.

IL is the backbone for every managed application. In a sense, the language is only recognized by .NET framework is IL. To understand IL, look at following program. Here we are creating a function with same operation in two language C# and VB.NET as following;

C# .Net Code

[c language="language="]

namespace Hello

{

    public class TestClass

    {

        public static void Main()

        {

            Console.WriteLine("Hello World");

        }

    }

}

[/c]
VB.NET Code
[vbnet]Module Hello

    Public Class TestClass

        Public Shared Sub Main()

            Console.WriteLine("Hello World")

        End Sub

    End Class

End Module

[/vbnet]

If you examine their IL code produced by the .NET framework, the ILDASM.exe utility after compiling both programs is using csc.exe and vbc.exe. You will find the same IL code in both languages. Written programs as following:

Finally, the managed code enables platform independence. You can compile to IL from one language, and this compiled code should be interoperable with another IL compiled language.
Common Types System


The CTS specification describes all possible data types and programming constructs supported by the runtime, specifies how these entities can interact with each other, and details how they are represented in the .NET metadata format. Types are the mechanism by which code written in one language can talk to code written in different programming language. CTS defines the predefined data types that are available in IL code, so that all languages that targets the .NET CLR will produce compile code that is based on these types.
Suppose that one of the methods is defined in VB.net class that returns an Integer, and if we call this method in C# defined class by implementing the inheritance but C# does not have any data type of that name. So this problem is circumventing by CTS. In VB.net Integer is actually a 32-bit signed integer that maps exactly to the IL type code, known as Int32. At source level, C# refers to Int32 with the keyword int. so the compiler will simply treat the VB.net methods as if it returned an int.
Note: you can explore the various languages supported by .NET framework from www.dotnetlanguages.net


CTS also established the rules by which assemblys form, a boundary of visibility for a type. In addition, the CTS define the rules governing inheritance, object life time and virtual methods for instance all types must be inherit from predefined type System.Object;
Common Language Specification


The .NET framework was designed to support multiple languages. During the design phase of .NET, Microsoft invited many compiler vendors to build their own .NET languages.
The Common Language Specification works with the CTS to ensure language interoperability. Each language express the same programming constructs in specific terms. For example, in VB.NET you denote string concatenation using the ampersand (&), while in C# you typically make use of plus (+) operator. So the CLS is untimely a set of rules that compilers builders must conforms to if they intended their code to be compliant with other .NET supported languages.
However, not all types are available to all programming language. To build components accessible from all .NET languages, use the CLS. With the CLS, the compiler can check for valid code according to the CLS specification.
With the CLSComplaint attribute, you can mark your assembly as CLS-compliant. Doing this guarantees that the classes in this assembly can be used from all .NET consumer tools. You can instruct the C# compiler as following:
[assembly: System.CLSCompliant(true)]


Garbage Collection


The lower-level high performance language such as C, C++ is used to clean memory locations for occupied resources manually. For efficiency's sake, it is better that resources are never occupied for longer than necessary, but such mechanism has one huge disadvantage–the frequency of bugs. Code that requests memory should explicitly inform the system when it is no longer required that memory. Those process often resulting in memory leaks and easily overlooked by implementing .NET framework feature Garbage Collection.
.NET runtime relies on Garbage Collection to release resource from memory automatically instead. All dynamically requested memory is allocated on heap so when, .NET detects that the managed heap for a given process is becoming full, it call the garbage collector. It clean out the Reference of objects or variable running in current scope stored from heap automatically.
The most important aspect of garbage collection is that it is not deterministic. You can't guarantee when the garbage collector will be called; it would be called when CLR decides that it is needed to release the resources from memory.
Assemblies


An assembly contains CIL (Common Intermediate Code) code, which is conceptually similar to java byte code. In addition to CIL instruction, assemblies also contain metadata that describes in vivid detail the characteristics of every type in the binary. The .NET metadata is always present within an assembly and is automatically generated by .NET aware language compiler. When a *.exe or *.dll is created using .NET aware compiler, it is referred to as an assembly.
Assemblies themselves are also described using metadata, which is officially termed as manifest. The manifest contains information about the current version of assembly, culture information and a list of all externally reference assemblies that required executing the program.
Technically speaking, the .NET assembly is composed of single file or multiple file assembly. Single file assembly contains all the necessary CIL, metadata and manifest in an autonomous. On the other hand, multiple file assemblies are composed of numerous .NET binaries, each of which is called a module. If you are building an executable desktop application m the *.exe can simply be referred to as an assembly. Likewise if you are creating a class library, then *.dll would be referred as an assembly.
The .NET assemblies can categories into Shared Assemblies and Private Assembly. Shared Assemblies are intended to be common libraries that any other application can reference them whereas Private Assemblies are simplest type, normally ship with software and intended to be used only with that software.
Reflection


It is possible to access the metadata (vivid details about types) from an assembly programmatically using the Reflection mechanism. This method is commonly used to obtain the details of attributes, although you can also use reflection, among other purpose, such as instantiating classes or calling methods.
In this way, you could select classes to instantiate methods to call at runtime, rather than compile time, based on user inputs (Dynamic Binding). Reflection allows us to perform numerous tasks such as enumerating members of type, finding out information of types, creating and compiling new assemblies, and inspecting the custom attributes applied to type.
Security


Security is an essential part of any application and should be taken into consideration from the first stage of the development process. The .NET framework secures the resources by implementing various full-fledged security mechanisms; such authentication, authorization, code access, role based security, sandboxing and certificate security. Furthermore, the .NET framework on its own provides you with a set of base classes for implementing confidentiality and integrity through encryption and digital signature.
The .NET allows you to manage security, including how .NET protects you from malicious code, how to administer security policies and how to access the security subsystems programmatically. The .NET framework security mainly revolves around code access security and role base security.
Code Access Security (CAS) reduces the risks associated with running code of dubious origin even if code is running under super user account. It is possible to use CAS to indicate that code should still not be permitted to perform certain type of operations. Whereas Role-Based security is based on the identity of the account under which the process is running, CLR is able to inspect code before running in order to determine required security permissions.
Open Source Nature


This article briefly comments on the platform-independent open source nature of .NET framework. When Microsoft released the .NET platform, they crafted a set of formal documents that describes the syntax and semantics of the CIL language which is known as Virtual Execution System. The .NET assemblies can be developed and executed on non-Microsoft operating systems such UNIX, Mac OS, Linux, FedoraFedora, and other various Linux distributions. The Mono project is an open source distribution of Common Language Infrastructure that targets various Linux distribution as well as Windows and Mac OS/ iPhone devices.
Conclusion




        


                

        
    


            

Learn Digital Forensics                
            

            

                
Build your skills with hands-on forensics training for computers, mobile devices, networks and more.
            
                

                    
                        Start Learning
                    
                
    

This article has covered a lot of ground, briefly reviewing important aspects of the .NET framework. It started by discussing the advantages of the framework, and the compilation process executing by CLR. As you have seen, an assembly contains CIL instructions that are compiled to platform-specific instructions using the JIT compiler. This article explores the important role of CLS and CTS .You will also get the understanding of assemblies, garbage collection, reflection and security offered by Common Language Runtime.