The CLS (or Common Language Specification) is a simply a contract between

programming language designers and class library authors.  On the one hand
the language designers such as C#, VB, C++, Cobol, Eiffel, FORTRAN, etc
agree to extend their languages to support, through some means, the ability
to access functionality exposed with features from the CLS.   On the other
hand library designers (such as the .NET Framework, WinFX, 3 rd party
controls, etc) agree to expose all their functionality in such a way that it can
be used with just those features from the CLS.  
 
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. 
The first thing you will notice is that the CLS is weighted very heavily in favor
of the library designers.  Nearly every meaningful feature of the CLR is
exposed in the CLS.    We initially started with the idea that we’d just use the
subset of all programming languages but quickly discovered that would leave
only calling static methods (if that).  So we opted, wisely, to include nearly
everything a library designer might need.  This is actually a big win for
language vendors because at least they have a clearly spelled out list of
things they need to support.  It is not something you find out by testing
1,000s of libraries in the wild.  
 
Why should you care?  Well, if you are just building end applications or
libraries that will only be used by a single language don’t worry about the
CLS.  Use all the features your language of choice offers you.  If you are
building a library that you hope to be used by a wide range of developers you
might find it useful to conform to the CLS such that you have an open ended
market.  After all, who knows when that next big language will catch on and
be as big as VB, C# or C++?  Ruby, Python, etc all have a chance.  If you
conform to the CLS your library will be useable by that language.  Lastly, if
you are a language designer, it is clearly in your interest to take advantage
of the rich set of functionality exposed in the .NET Framework, WinFX and 3 rd
party libraries.  To do so, all you need to do is support all the CLS constructs.

.Net Common Language Specifications (CLS):

   In an object-oriented environment, everything is considered as an object.

(This point is explained in this article and the more advanced features are
explained in other articles.) You create a template for an object (this is called
the class file), and this class file is used to create multiple objects.
TIP: Consider a Rectangle. You may want to create many Rectangle in your
lifetime; but each Rectangle will have certain characteristics and certain
functions. For example, each rectangle will have a specific width and color.
So now, suppose your friend also wants to create a Rectangle. Why reinvent
the Rectangle? You can create a common template and share it with others.
They create the Rectangle based on your template. This is the heart of
object-oriented programming?the template is the class file, and the
Rectangle is the objects built from that class. Once you have created an
object, your object needs to communicate with many other Objects. 

   Even if it is created in another .NET language doesn?t matter, because

each language follows the rules of the CLS. The CLS defines the necessary
things as common variable types (this is called the Common Type System
CTS ), common visibility like when and where can one see these variables,
common method specifications, and so on. It doesn?t have one rule which
tells how C# composes its objects and another rule tells how VB .Net does
the same thing . To steal a phrase, there is now ?One rule to bind them all.?
One thing to note here is that the CLS simply provides the bare rules.
Languages can adhere to their own specification. In this case, the actual
compilers do not need to be as powerful as those that support the full CLS.

The Common Language Runtime (CLR):

   The heart of .net Framework is Common Language Runtime (CLR). All

.NET-compliant languages run in a common, managed runtime execution
environment. With the CLR, you can rely on code that is accessed from
different languages. This is a huge benefit. One coder can write one module
in C#, and another can access and use it from VB .Net. Automatic object
management, the .NET languages take care of memory issues automatically.
These are the few listed?benefits which you get from CLR.

Microsoft Intermediate Language (MSIL):

   So how can many different languages be brought together and executed

together??Microsoft Intermediate Language (MSIL) or, as it?s more
commonly known, Intermediate Language (IL). In its simplest terms, IL is a
programming language.?If you wanted to, you could write IL directly,
compile it, and run it. But why would want to write such low level code?
Microsoft has provided with higher-level languages, such as C#, that one can
use. Before the code is executed, the MSIL must be converted into platform-
specific code. The CLR includes something called a JIT compiler in which the
compiler order is as follows. 

Source Code => Compiler => Assembley =>Class Loader =>Jit Compiler
=>Manged Native Code=>Execution.

  The above is the order of compilation and execution of programs. Once a

program is written in a .Net compliant language, the rest all is the
responsibility of the frame work.

To fully interact with other objects regardless of the language they were
implemented in, objects must expose to callers only those features that are
common to all the languages they must interoperate with. For this reason,
the Common Language Specification (CLS), which is a set of basic language
features needed by many applications, has been defined. The CLS rules
define a subset of the common type system; that is, all the rules that apply
to the common type system apply to the CLS, except where stricter rules are
defined in the CLS. The CLS helps enhance and ensure language
interoperability by defining a set of features that developers can rely on to be
available in a wide variety of languages. The CLS also establishes
requirements for CLS compliance; these help you determine whether your
managed code conforms to the CLS and to what extent a given tool supports
the development of managed code that uses CLS features.

If your component uses only CLS features in the API that it exposes to other
code (including derived classes), the component is guaranteed to be
accessible from any programming language that supports the CLS.
Components that adhere to the CLS rules and use only the features included
in the CLS are said to be CLS-compliant components.

Most of the members defined by types in the .NET Framework class library
are CLS-compliant. However, some types in the class library have one or
more members that are not CLS-compliant. These members enable support
for language features that are not in the CLS. The types and members that
are not CLS-compliant are identified as such in the reference documentation,
and in all cases a CLS-compliant alternative is available. For more
information about the types in the .NET Framework class library, see the
.NET Framework Reference.

The CLS was designed to be large enough to include the language constructs
that are commonly needed by developers, yet small enough that most
languages are able to support it. In addition, any language construct that
makes it impossible to rapidly verify the type safety of code was excluded
from the CLS so that all CLS-compliant languages can produce verifiable code
if they choose to do so. For more information about verification of type
safety, see JIT Compilation.

The following table summarizes the features that are in the CLS and indicates
whether the feature applies to both developers and compilers (All) or only
compilers. It is intended to be informative, but not comprehensive. For
details, see the specification for the Common Language Infrastructure,
Partition I, which is located in the Tool Developers Guide directory installed
with the Microsoft .NET Framework SDK.

Common Type System

The common type system defines how types are declared, used, and
managed in the runtime, and is also an important part of the runtime's
support for cross-language integration. The common type system performs
the following functions:
  Establishes a framework that helps enable cross-language integration,
type safety, and high performance code execution.
 Provides an object-oriented model that supports the complete
implementation of many programming languages.
 Defines rules that languages must follow, which helps ensure that
objects written in different languages can interact with each other.

JIT compiler is a part of the runtime execution environment.

In Microsoft .NET there are three types of JIT compilers:

• Pre-JIT: - Pre-JIT compiles complete source code into native code in a

single
compilation cycle. This is done at the time of deployment of the application.
• Econo-JIT: - Econo-JIT compiles only those methods that are called at
runtime.
However, these compiled methods are removed when they are not required.
• Normal-JIT: - Normal-JIT compiles only those methods that are called at
runtime.

These methods are compiled the first time they are called, and then they are
stored in cache. When the same methods are called again, the compiled code
from cache is used for execution.

When compiling the source code to managed code, the compiler translates
the source into Microsoft intermediate language (MSIL). This is a CPU-
independent set of instructions that can efficiently be converted to native
code. Microsoft intermediate language (MSIL) is a translation used as the
output of a number of compilers. It is the input to a just-in-time (JIT)
compiler. The Common Language Runtime includes a JIT compiler for the
conversion of MSIL to native code.

Before Microsoft Intermediate Language (MSIL) can be executed it, must be

converted by the .NET Framework just-in-time (JIT) compiler to native code.
This is CPU-specific code that runs on the same computer architecture as the
JIT compiler. Rather than using time and memory to convert all of the MSIL
in a portable executable (PE) file to native code. It converts the MSIL as
needed whilst executing, then caches the resulting native code so its
accessible for any subsequent calls.