.NET Framework

The Microsoft .NET Framework is a software component that can be added to or is included with the Microsoft Windows operating system. It provides a large body of pre-coded solutions to common program requirements, and manages the execution of programs written specifically for the framework. The .NET Framework is a key Microsoft offering, and is intended to be used by most new applications created for the Windows platform. First released in 2002, it is included with Windows Server 2003 and Windows Vista, and can be installed on most older versions of Windows.

Design goals and principal features Interoperability - Because interaction between new and older applications is commonly required, the .NET Framework provides means to access functionality that is implemented in programs that execute outside the .NET environment. Security - .NET allows for code to be run with different trust levels Simplified Deployment - Installation of computer software must be carefully managed to ensure that it does not interfere with previously installed software, The .NET framework includes design features and tools that help address these requirements.

Common Runtime Engine - Programming languages on the Common Runtime Engine - Programming languages on the .NET Framework compile into an intermediate language known as the Common Intermediate Language, or CIL; Microsoft's implementation of CIL is known as Microsoft Intermediate Language, or MSIL. This intermediate language is not interpreted, but rather compiled in a manner known as just-in-time compilation (JIT) into native code. The combination of these concepts is called the Common Language Infrastructure (CLI) Microsoft's implementation of the CLI is known as the Common Language Runtime (CLR).

Language Independence - The Language Independence - The .NET Framework introduces a Common Type System, or CTS. The CTS specification defines all possible datatypes and programming constructs supported by the CLR and how they may or may not interact with each other. Because of this feature, the .NET Framework supports development in multiple programming languages Base Class Library - The Base Class Library (BCL), sometimes referred to as the Framework Class Library (FCL), is a library of types available to all languages using the .NET Framework. The BCL provides classes which encapsulate a number of common functions, including file reading and writing, graphic rendering, database interaction and XML document manipulation.

platform independence A design goal of the .NET Framework is to support platform independence. That is, a program written to use the framework should run without change on any type of computer for which the framework is implemented. However, Microsoft has only implemented the full .NET framework on the Windows operating system. Microsoft and others have implemented portions of the framework on non-Windows systems, but to date these implementations are neither complete nor widely used, so cross-platform support is not yet fully achieved.

NET Framework architecture Common Language Infrastructure (CLI) Assemblies Metadata Base Class Library (BCL)

Common Language Infrastructure (CLI)

CLR Programs written for the .NET Framework execute in a software environment that manages the program's runtime requirements. This runtime environment, which is also a part of the .NET Framework, is known as the Common Language Runtime (CLR). The CLR provides the appearance of an application virtual machine, so that programmers need not consider the capabilities of the specific CPU that will execute the program. The CLR also provides other important services such as security mechanisms, memory management, and exception handling. The class library and the CLR together compose the .NET Framework.

Microsoft's implementation of the CLI is called the Common Language Runtime, or CLR. The CLR is composed of four primary parts: Common Type System (CTS) Common Language Specification (CLS) Just-In-Time Compiler (JIT) Virtual Execution System (VES)

Common Type System (CTS) The Common Type System (CTS) is used by every language built on the .NET Framework. A fundamental part of the .NET Framework is Common Language Runtime (CLR), the CTS specifies no particular syntax or keywords, but instead defines a common set of types that can be used with many different language syntaxes. Each language is free to define any syntax it wishes, but if that language is built on the CLR, it will use at least some of the types defined by the CTS. While the creator of a CLR-based language is free to implement only a subset of the types defined by the CTS. Visual Basic.NET, C#, and pretty much every other language used with the .NET Framework rely heavily on the CTS.

The CTS provides every language running on the The CTS provides every language running on the .NET platform with a base set of data types. While the CTS is responsible for defining the types that can be used across the .NET languages, most languages choose to implement aliases to those types. A four-byte integer value is represented by the CTS type System.Int32. C# defines an alias for this type called int.

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

The Common Type System (CTS) Among other things CLI specification describes the following four aspects: The Common Type System (CTS)  A set of types and operations that are shared by all CTS-compliant programming languages. Metadata  Information about program structure is language-agnostic, so that it can be referenced between languages and tools, making it easy to work with code written in a language you are not using. Common Language Specification (CLS)  A set of base rules to which any language targeting the CLI should conform in order to interoperate with other CLS-compliant languages. Virtual Execution System (VES)  The VES loads and executes CLI-compatible programs, using the metadata to combine separately generated pieces of code at runtime.

just-in-time compilation (JIT) In computing, just-in-time compilation (JIT), also known as dynamic translation, is a technique for improving the runtime performance of a computer program. It converts, at runtime, code from one format into another, for example bytecode into native machine code. The performance improvement originates from caching the results of translating blocks of code, and not simply evaluating each line or operand separately (see Interpreted language), or compiling the code at development time. JIT builds upon two earlier ideas in run-time environments: bytecode compilation and dynamic compilation

In a bytecode-compiled system, source code is translated to an intermediate representation known as bytecode. Bytecode is not the machine code for any particular computer, and may be portable among computer architectures. The bytecode is then interpreted, or run on a virtual machine. A dynamic compilation environment is one in which the compiler can be used during execution. For instance, most Common Lisp systems have a compile function which can compile new functions created during the run. While advantageous in interactive debugging, dynamic compilation is less useful in a hands-off deployed system.

In a JIT environment, bytecode compilation is the first step, reducing source code to a portable and optimizable intermediate representation. The bytecode is deployed onto the target system. When code is executed, the runtime environment's compiler translates it into native machine code. This can be done per-file, per-function or even on any arbitrary code fragment; code can be compiled when it is about to be executed (hence the name "just-in-time").

The goal is to combine many of the advantages of native and bytecode compilation: Much of the "heavy lifting" of parsing the original source code and performing basic optimization is handled at compile time, prior to deployment: compilation from bytecode to machine code is much faster than from source. The deployed bytecode is portable, unlike machine code for any given architecture. Compilers from bytecode to machine code are easier to write, because the portable bytecode compiler has already done much of the work. This also generally offers far better performance than interpreters as the compiled code is stored in memory cache at runtime, such that subsequent recompilation or reinterpretation of compiled code can be skipped, while also giving flexibility to automatically recompile and optimise code that is found at runtime to be frequently executed.

However, JIT may have a drawback by causing a slight delay in initial execution of an application, due to the time taken to compile the bytecode. Sometimes this delay is called "startup time delay". In general, the more optimization JIT performs, the better code it will generate. However, the longer delay users will experience. Therefore a well written JIT has to make the trade-offs between the compilation time and the quality of the code it hopes to generate.

Other advantages of a JIT runtime include: The compilation can be optimized to the targeted CPU and the operating system model where the application runs. The system is able to collect statistics about how the program is actually running in the environment it is in, and it can rearrange and recompile for optimum performance. This data is normally difficult or even impossible to obtain for conventional compilers.

JIT compilation is considered advantageous in many scenarios because of its portability, flexibility and performance. The only major drawback is the startup time delay

Virtual Execution System (VES) The Virtual Execution System(VES) provides an environment for executing managed code. It provides direct support for a set of built-in data types, defines a hypothetical machine with an associated machine model and state, a set of control flow constructs, and an exception handling model. To a large extent, the purpose of the VES is to provide the support required to execute the Common Intermediate Language instruction set.

.NET assemblies The intermediate MSIL code is housed in .NET assemblies, which for the Windows implementation means a Portable Executable (PE) file (EXE or DLL) Assemblies are the .NET unit of deployment, versioning and security. The assembly consists of one or more files, but one of these must contain the manifest, which has the metadata for the assembly. The complete name of an assembly contains its simple text name, version number, culture and public key token; it must contain the name, but the others are optional.

The public key token is generated when the assembly is created, and is a value that uniquely represents the name and contents of all the assembly files, and a private key known only to the creator of the assembly. Two assemblies with the same public key token are guaranteed to be identical. If an assembly is tampered with (for example, by hackers), the public key can be used to detect the tampering.

.NET metadata All CIL is Self-Describing through .NET metadata. The CLR checks on metadata to ensure that the correct method is called. Metadata is usually generated by language compilers but developers can create their own metadata through custom attributes. Metadata also contain all the information about assembly.

The Base Class Library (BCL), sometimes incorrectly referred to as the Framework Class Library (FCL) (which is a superset including the Microsoft.* namespaces), is a library of classes available to all languages using the .NET Framework. The BCL provides classes which encapsulate a number of common functions such as file reading and writing, graphic rendering, database interaction, XML document manipulation, and so forth. The BCL is much larger than other libraries, but has much more functionality in one package.

managed code In Microsoft Windows terminology, managed code is computer instructions — that is, "code" — executed by a CLI-compliant virtual machine, such as Microsoft's .NET Framework Common Language Runtime, or other CLI implementations from The Mono Project or the DotGNU Project. Before the code is run, the Intermediate Language is compiled into native machine code. Since this compilation happens by the managed execution environment's own runtime-aware compiler, the managed execution environment can guarantee what the code is going to do.

This is traditionally referred to as Just-in-time compilation In a Microsoft Windows environment, all other code has come to be known as unmanaged code or sometimes incorrectly native code Managed refers to the relationship between the program and the runtime environment. It is specified that at any point of execution, the runtime may stop the executing program and retrieve information specific to its current runtime state. The necessary information is then encoded in Common Intermediate Language (formerly known as Microsoft Intermediate Language) and associated metadata.

.NET Framework Architecture

.NET Assembly                                                                                                                                                        .NET Assembly Assemblies consist of IL Code and Metadata. Where metadata determines the application dependencies.

Architecture of .NET Framework CLR

Class loader, which loads classes into CLR. MSIL to native code compiles, this converts MSIL code into native code. Code manager, this manages the code during execution. Memory allocation and Garbage collector, this performs automatic memory management. Security engine, this enforces security restrictions as code level security folder level and machine level security using tools provided by Microsoft .NET and using .NET Framework setting under control panel. Type checker, which enforces strict type checking. Thread support, which provides multithreading support to applications. Exception manager, which provides a mechanism to handle the run-time exceptions handling.

Debug engine, which allows developer to debug different types of applications. COM marshaler, which allows .NET applications to exchange data with COM applications. Base class library support, which provides the classes (types) that the applications need at run time.

Features of the Common Language Runtime The CLR has the following Features Manages memory, Allocation of Memory De-Allocation of Memory (garbage collation) Thread execution support, Code execution, Code safety verification, Compilation. MSIL to Native Code. Code Security based on Trust (granted permission to execute code. Code level, Folder level, Machine level) These features are intrinsic to the managed code that runs on the common language runtime.

To execute the program and gain all the benefits of managed execution environment we write code in a language which is supported by CLS that is .NET Framework. The language compiler compiles the source code into the MSIL code which consists of CPU- independent code and instructions which is platform independent. MSIL consists of the followings: Instructions that enables to perform arithmetic and logical operations Access memory directly. Control the flow of execution, Handles exceptions,

MSIL code can be compiling into CPU specific instructions before executing, for which the CLR requires information about the code which is nothing but metadata. Metadata describes the code and defines the types that the code contains as well referenced to other types which the code uses at run time. An assembly consists of portable executable file. At the time of executing PE file the class loader loads the MSIL code and the metadata from the portable executable file into the run time memory. Before the execution of PE file it passes the code to the native code compiler for compilation, IL to native code compilation is done by JIT compiler. For different CPU architecture and compilers for the IL code in to the native instructions

Understanding JIT compiler

JIT compiler is the integral part of CLR. The compiler compiles MSIL code to Native code and executes the batch of code Just in time which will be cached Next time the code gets executed from cache in stead of compiling again. CLR class loader loads MSIL code and metadata the code manager calls the entry point method which is WinMain or DLLMain method. The JIT compiler compiles the method before its execution of the entry point method. The code manager places the objects in memory and controls the execution of the code. The garbage collector performs periodic checks on the managed heap to identify the objects which is not in use for the application.

At the time of program execution the type checker ensures that all objects and values, and the references of objects and values has its valid type. The type checker also makes sure that only valid operations are performed on the code other wise the exception will be thrown. The code is controlled by CLR at run time. CLR enforces security in following manner. To control and access the system recourses like hard disk To control and access the network connections To control and access the other hard ware resources.