HOW CLR PROVIDES CROSS LANGUAGE INTERACTION

A component can be called by any .NET-based language regardless the original language of that component. The cross-language compatibility is possible because objects created in different .NET languages agree on a common set of types and features. These common types and features are spelled out in the Common Language Specification (CLS).

Let’s take a look how CLR provide cross language interaction:

1. Every .NET based language compiler translates source language program into MSIL code.

2. The CLR also defines, the format' of storing assembly metadata and this means all assemblies whatever language they were written in, share a common format for storing Metadata. '

3. All .NET based language follow Common Language Specification (CLS). CLS specifies a set of features that every .NET complaint language has to follow. A .NET complaint language may have its own unique features but it must follow the common set of features specified in CLS.

Because the target code of each .NET based compiler is represented in same language. The metadata is expressed in same language 'and all sources language confirms to follow a set of features so the codes written in two different languages can interoperate.

Common Language Infrastructure (CLI)

The Common Language Infrastructure (CLI) is an open specification developed by Microsoft that describes the executable code and runtime environment that allows multiple high-level languages to be used on different computer platforms without being rewritten for specific architectures. CLR is Microsoft Commercial implementation of Common Language Infrastructure (CLI).

       The Common Language Infrastructure (CLI) is a theoretical model of a development platform that provides a device and language independent way to express data and behavior of applications.

While the CLI primarily supports Object Oriented Programming (OOP) languages, procedural and functional languages are also supported. Through the CLI, languages can interoperate with each other and make use of a built-in garbage collector, security system, exception support, and a powerful framework.

Garbage Collection

When you initialize a variable using the new operator, you are in fact asking the compiler to provide you some memory space in the heap memory. The compiler is said to "allocate" memory for your variable. When that variable is no longer needed, such as when your program closes, it (the variable) must be removed from memory and the space it was using can be made available to other variables or other programs. This is referred to as garbage collection. In the past, namely in C/C++, this was a concern for programmers because they usually had to remember to manually delete such a variable (a pointer) and free its memory.

The .NET Framework solves the problem of garbage collection by letting the compiler "clean" memory after you. This is done automatically when the compiler judges it necessary so that the programmer doesn't need to worry about this issue.

Garbage collection is a mechanism that allows the computer to detect when an object can no longer is accessed. It then automatically releases the memory used by that object (as well as calling a clean-up routine, called a "finalizer" which is written by the user). Some garbage collectors like the one used by .NET, compact memory and therefore decrease your program's working set.

For most programmers, having a garbage collector (and using garbage collected objects) means that you never have to worry about deallocating memory, or reference counting objects, even if you use sophisticated data structures. It does require some changes in coding style, however, if you typically de-allocate system resources (file handles, locks, and so forth) in the same block of code that releases the memory for an object. With a garbage collected object you should provide a method that releases the system resources deterministically (that is, under your program control) and let the garbage collector release the memory: when it compact the working set.

Just in Time Compiler (JIT)

Machines cannot run MSIL directly. JIT compiler turns MSIL into native code, which is CPU specific code that runs on the same computer architecture as the JIT compiler. Because the common. Language runtime supplies a JIT compiler for each supported CPU architecture, developers can write a set of MSIL that can be JIT-compiled and run on computers with different architectures.

However, your managed code will run only on a specific operating system if it calls platform specific native APIs, or a platform-specific class library.

JIT compilation takes into account the fact that some code might never get called during execution. Rather than using time and memory to convert all the MSIL in a portable executable (PE) file to native code, it converts the MSIL as needed during execution and stores the resulting native code so that it is accessible for subsequent calls.

The loader creates and attaches a stub to each of a type's methods when the type is loaded. On the initial call to the method, the stub passes control to the JIT compiler, which converts the MSIL for that method into native code and modifies the stub to direct execution· to the location of the native code. Subsequent calls of the JIT -compiled method proceed directly to the native code that was previously generated, reducing the time it takes to JIT-compile and run the code.

Managed and Unmanaged Code

Managed code is code that is written to target the services of the common language runtime. In order· to target these services, the code must provide a minimum level of information (metadata) to the runtime. All C#, Visual Basic .NET, and JScript .NET code is managed by default. Visual Studio .NET C++ code is not managed by default, but the compiler can produce managed code by specifying a command-line switch (/CLR).

CLR (Common Language Runtime)

Common Language Runtime is the heart of .NET Framework used to manage the program written in .NET Framework compatible language (E.g. C#, Vb.NET, J# etc.). In other words, CLR is Execution Engine which executes the program for .NET Framework.

It provides a number of services, including the following:

ü  Code management (loading and execution)

ü  Application memory isolation

ü  Verification of type safety

ü  Conversion of IL to native code

ü  Access to metadata (enhanced type information)

ü  Managing memory for managed objects

ü  Enforcement of code access security

ü  Exception handling, including cross-language exceptions

ü  Interoperation between managed code, COM objects, and pre-existing DLLs

ü  Automation of object layout

ü  Support for developer services (profiling, debugging, and so on)

The Common Language Runtime (CLR) is the virtual machine component of Microsoft's .NET initiative. It is Microsoft's implementation of the Common Language Infrastructure (CLI) standard, which defines an execution environment for program code. The CLR runs a form of byte code called the Common Intermediate Language (CIL, previously known as MSIL (Microsoft Intermediate Language)

How CLR Works?

When we write a program in .NET compatible language, then the compiler for C# or VB.NET compiles the code in IL (Intermediate Language) or MSIL (Microsoft Intermediate Language) and then IL will be the input of CLR's component Just in Time compiler to produce machine independent code.

Apart from the above CLR is also responsible for:

Memory management

Thread management

Exception handling

Garbage collection

Security

CTS (Common Type System) & MSIL

Common Type System is the part of .NET Framework built in with CLR which is responsible for defining, managing different language's operation supported by .NET Framework. CTS are responsible for cross language Integration (Means you can have a dll which is written in C# and to be used in VB.Net application) and Type Safety. It enforces a set of rules that a programming language must follow.

Types of CTS (Common Type System)

The common type system supports two general categories of types:

1. Value types

Value types directly contain their data, and instances of value types are either allocated on the stack or allocated inline in a structure. Value types can be built-in, user-defined or enumerations types.

2. Reference types

Reference types stores a reference to the value's memory address, and are allocated on the heap. Reference types can be self-describing types, pointers types, or interface types. The type of a reference type can be determined from values of self-describing types. Self-describing types are further split into arrays and class types are user-defined classes, boxed value types, and delegates.

CTS, much like Java, define every data type as a Class. Every .NET compliant language must stick to this definition. Since CTS defines every data type as a class; this means that only Object-Oriented (or Object-Based) languages can achieve .NET compliance.

Microsoft Intermediate Language (MSIL)

A .NET programming language (C#, VB.NET, J# etc.) does not compile into executable code; instead it compiles into an intermediate code called Microsoft Intermediate Language (MSIL). As a programmer one need not worry about the syntax of MSIL - since our source code in automatically converted to MSIL. The MSIL code is then send to the CLR (Common Language Runtime) that converts the code to machine language which is then run on the host machine. MSIL is similar to Java Byte code. A Java program is compiled into Java Byte code (the .class file) by a Java compiler, the class file is then sent to JVM which converts it into the host machine language.

Common Language Specification (CLS)

One of the obvious themes of .NET is unification and interoperability between various programming languages. In order to achieve this; certain rules must be laid and all the languages must follow these rules. In other words we cannot have languages running around creating their own extensions and their own fancy new data types. CLS is the collection of the rules and constraints that every language (that seeks to achieve .NET compatibility) must follow.

The Common Language Specification is a set of basic language features (constructs and constraints) that serves as a guide for library writers and compiler writers. It allows libraries to be fully usable from any language supporting the CLS, and for those languages to integrate with each other. The Common Language Specification is a subset of the common type system. The CLS is actually a set of restrictions on the CTS. The CLS defines not only the types allowed in external calls, but the rules for using them, depending on the goal of the user.

Informally CLS is a simply a contract between programming language designers and class library authors. The CLS is basically just a subset of the entire set of features supported by the CLR. The CLS includes things such as calling virtual methods, overloading methods and does not include things such as unsigned types. CLS is weighted very heavily in favor of the library designers.

The Common Language Specification describes a common level of language functionality. The CLS is a set of rules that a language compiler must adhere to in order to create .NET applications that run in the CLR. Anyone who wants to write a .NET·-compliant compiler needs simply to adhere to these rules and that's it. The relatively high minimum bar of the CLS enables the creation of a club of CLS-compliant languages. Each member of this club enjoys dual benefits: complete access to .NET framework functionality and rich interoperability with other compliant languages. For example a VB class can inherit from a C# class and override its virtual methods.

The common language specification (CLS) is a collection of rules and restrictions that allow interoperation between languages. Even though the CLI does not require compilers to follow CLS, code that follows the CLS rules is compatible with all other languages that follow the CLS rules.

Microsoft has defined three level of CLS compatibility/compliance. The goals and objectives of each compliance level have been set aside. The three compliance levels with their brief description are given below:

1. Compliant producer

The component developed in this type of language can be used by any other language.

2. Consumer

The language in this category can use classes produced in any other language. In simple words this means that the language can instantiate classes developed in other language. 

3. Extender

Languages in this category cannot just use the classes as in CONSUMER category; but can also extend classes using inheritance. Languages that come with Microsoft Visual Studio namely Visual C++, Visual Basic and C#; all satisfy the above three categories. Vendors can select any of the above categories as the targeted compliance level(s) for their languages.