CLR Basics:

The CLRs Execution Model

Agenda

CLR Execution Model

Compiling source code into

Managed modules

The Native Code Generator Tool:

NGen.exe

Introducing the Framework

Class Library

The Common Type System

The Common Language

Specification

Interoperability with
Unmanaged code

Combining Managed Modules

into Assemblies

Loading the Common Language

Runtime

Executing your Assemblys code

IL and Verification

Unsafe Code

CLR Execution Model

Compiling Source Code into Managed Modules

Language compilers are syntax checkers and "correct code" analyzers.

Microsoft has created several language compilers (C++, C# ,Visual Basic,

JScript, J#,etc..) that produce code that targets CLR.

In addition to Microsoft, several other companies, colleges, and universities

have created compilers that produce code to target the CLR.

Example :

Compilers for Ada, APL, Caml, COBOL, Eiffel, Forth, Fortran, Haskell,
Lexico, LISP, LOGO,Lua, Mercury, ML, Mondrian, Oberon, Pascal, Perl, Php,
Prolog, Python, RPG, Scheme, Smalltalk, and Tcl/Tk.

These compilers check the syntax and analyze the source code and generate a
Managed Module.

Compiling Source Code into Managed Modules

A managed module is a standard 32-bit Microsoft Windows portable

executable (PE32) file or a standard 64-bit Windows portable
executable (PE32+) file that requires the CLR to execute.

Parts of a Managed Module

PE32 or PE32+ header

CLR header

Metadata or Metadata Table

Intermediate Language (IL) code

PE32 or PE32+ header

If the header uses the PE32 format, the file can run on a 32-bit or 64-bit version of
Windows.

If the header uses the PE32+ format, the file requires a 64-bit version of Windows to
run.

Also indicates the type of file: GUI, CUI, or DLL, and contains a timestamp indicating
when the file was built.

CLR header

Contains the information that makes this a managed module.

Version of the CLR required, module's entry point method (Main method), and the
location/ size of the module's metadata, resources, strong name, some flags, and
other less interesting stuff.

Parts of a Managed Module

Metadata or Metadata Table

Tables that describe the types and members defined in your

source code

Tables that describe the types and members referenced by your

source code.

Intermediate Language (IL) code

Code the compiler produced as it compiled the source code.

At run time, the CLR compiles the IL into native CPU

instructions.

Parts of Managed Module

To get information about Managed Module , execute the following

command in VS command prompt;

Dumpbin / all <assembly_name> > result.txt

The above command would result with result.txt file which contains
the PE header information , CLR Header , Metadata and IL code.

Also can use ildasm a tool to view the IL code and Metadata
information. (Will discuss in next chapter.)

Combining Managed Modules into Assemblies

Combining Managed Modules into Assemblies

An assembly is a logical grouping of one or more modules or resource

files.

Also an assembly is the smallest unit of reuse, security and

versioning.

Assembly is either an .exe file or .dll file.

For projects that have just one managed module and no resource (or
data) files, the assembly will be the managed module.

Manifest within assembly contains information about Managed module

in the assembly.

There are tools to create assembly with more than one managed
module. (Discussed in next chapter.)

Loading the Common Language Runtime

Each assembly you build can be either an executable application or a

DLL containing a set of types for use by an executable application.

.Net Framework needs to be installed in the host machine that tries

to execute the exe or use the dll.

MSCorEE.dll file in the %SystemRoot%\system32 directory.

Several versions of the .NET Framework can be installed on a single

machine.

A command-line utility called CLRVer.exe shows all of the CLR

versions installed on a machine.

Version of CLR to be invoked by the assembly is mention in the

manifest.

Selecting Windows Version

In visual studio , under project's property pages, click the Build tab,
and then selecting an option in the Platform Target list.

Executing Your Assembly's Code

Usually, developers will program in a high-level language, such as C#,

C++/CLI, or Visual Basic.

The compilers for these high-level languages produce IL.

IL code is converted to native CPU instructions by the CLR's JIT (justin-time) compiler.

Lets see an example;

Executing Your Assembly's Code

Executing Your Assembly's Code

Just before the Main method executes, the CLR detects all of the
types that are referenced by Main's code.

Then CLR allocates an internal data structure that is used to manage

access to the referenced types.

Here ,the Main method refers to a single type, Console, causing the
CLR to allocate a single internal structure.

This internal data structure contains an entry for each method

defined by the Console type. Each entry holds the address where the
method's implementation can be found.

This data structure will be used by the JIT compiler in the CLR.

Executing Your Assembly's Code

When Main makes its first call to WriteLine, the JITCompiler is called.

When called, the JITCompiler knows what method is being called and what
type defines this method.

JIT compiler then searches the internal data structure to verify the structure
and syntax of the method and finally compiles the IL code into native CPU
instructions.

The native CPU instructions are saved in a dynamically allocated block of

memory.

Then, JITCompiler goes back to the entry for the called method in the type's
internal data structure created by the CLR and replaces the reference that
called it in the first place with the address of the block of memory containing
the native CPU instructions it just compiled.

Finally, the JITCompiler function jumps to the code in the memory block.

Executing Your Assembly's Code

Main now calls WriteLine a second time. This time, the code for
WriteLine has already been verified and compiled. So the call goes
directly to the block of memory, skipping the JITCompiler function
entirely. After the WriteLine method executes, it returns to Main.

Executing Your Assembly's Code

A performance hit is incurred only the first time a method is called.

All subsequent calls to the method execute at the full speed of the
native code because verification and compilation to native code do not
need to be performed again.

The JIT compiler stores the native CPU instructions in dynamic

memory.

This means that the compiled code is discarded when the application
terminates.

The Native Code Generator Tool: NGen.exe

The NGen.exe tool that ships with the .NET Framework can be used to compile
IL code to native code when an application is installed on a user's machine.

The code gets compiled at install time, the CLR's JIT compiler does not have
to compile the IL code at run time, and this can improve the application's
performance.

Advantages :
Improving an application's startup time

compiles the IL code at run time.

Reducing an application's working set

compiles the IL to native code and saves the output in a separate file.

This file can be memory-mapped into multiple process address spaces

simultaneously, allowing the code to be shared; not every process/
AppDomain needs its own copy of the code.

The Native Code Generator Tool: NGen.exe

This new file is placed in a folder under the directory with a name like
C:\Windows\Assembly\NativeImages_v2.0.50727_32.

Whenever the CLR loads an assembly file, the CLR looks to see if a
corresponding NGen'd native file exists. If a native file cannot be
found, the CLR JIT compiles the IL code as usual.

Framework Class Library

Also called as Base Class Library (BCL)

The FCL is a set of DLL assemblies that contain several thousand

type definitions in which each type exposes some functionality.

FCL is a set of reusable object-oriented classes that provide basic

platform functionality, such as ;

Data access classes of ADO.NET

File system utility classes
networking classes (ex: DNS resolution) and
other network-related functionality etc.,

Developers can use the base classes directly or derive from these
classes to provide customized functionality.

Framework Class Library

All objects of BCL originate from class System

Some of the BCL are mentioned below;

System Root for all namespaces

System.Data Database classes
System.Text String manipulation
System.IO
File I/O
System.Windows.Forms Windows Forms
System.Web Web Forms
System.XML XML elements

The Common Type System

CTS defines how data types are going to be declared and managed in runtime.

In .Net Framework, System.Object is the common base type from where all
the other types are derived.

The types in .NET Framework are the base on which .NET applications,
components, and controls are built.

The Common Type System performs the following functions:

Automatic integration of multiple languages,

type safety

high performance code execution.

Provides an object-oriented model.

Standardizes the conventions that all the languages must follow.

Encapsulates data structures.

Common Type System

Language keywords map to common CTS classes

Common Language Specification

CLS is a specification that defines the rules to support language

integration in such a way that programs written in any language,
can interoperate with one another.

The CLS is a subset CLR, as well as a set of rules that language

and compiler designers must follow. (if interoperability is
needed.)

CLS provides the ability to inherit classes written in one .NET

language in any other .NET language and cross-language
debugging.

The rules defined by the CLS apply only to publicly exposed

features of a class.

Thank You