The Microsoft .Net Framework is a platform that provides tools and technologies you need to build Networked Applications as well as Distributed Web Services and Web Applications. The .Net Framework provides the necessary compile time and run-time foundation to build and run any language that conforms to the Common Language Specification (CLS).The main two components of .Net Framework are Common Language Runtime (CLR) and .Net Framework Class Library (FCL).

The Common Language Runtime (CLR) is the runtime environment of the .Net Framework that executes and manages all running code like a Virtual Machine. The .Net Framework Class Library (FCL) is a huge collection of language-independent and type-safe reusable classes.

The .Net Framework Class Libraries (FCL) is arranged into a logical grouping according to their functionality and usability is called Namespaces. In the following sections describes how to .Net Framework manages the code in compile time and run time.

 

The principal design features are:

1. Interoperability: This allows for .NET-developed programs to access functionalities in programs developed outside .NET.
2. Common Runtime Engine: Also known as the common language runtime, this allows programs developed in .NET to exhibit common behaviors in memory usage, exception handling and security.
3. Language Independence: Common language infrastructure specifications (CLI) allow for the exchange of data types between two programs developed in different languages.
4. Base Class Library: A library of code for most common functions–used by programmers to avoid repetitive rewriting of code.
5. Ease of Deployment: There are tools to ensure the ease of installing programs without interfering with previously installed applications.
6. Security: Programs developed in .NET are based on a common security model.

 

Net Architecture and .Net Framework basics:

1. Common Language Runtime (CLR): The heart of the .Net Framework. It is also called the .Net runtime. It resides above the operating system and handles all .Net applications. It handles garbage collection, Code Access Security (CAS) etc.

2. Microsoft Intermediate Language (MSIL) Code: When we compile our .Net code then it is not directly converted to native/binary code; it is first converted into intermediate code known as MSIL code which is then interpreted by the CLR. MSIL is independent of hardware and the operating system. Cross language relationships are possible since MSIL is the same for all .Net languages. MSIL is further converted into native code.

3. Just in Time Compilers (JIT): It compiles IL code into native executable code (exe or dlls). Once code is converted to IL then it can be called again by JIT instead of recompiling that code.

4. Framework class library: The .Net Framework provides a huge class library called FCL for common tasks. It contains thousands of classes to access Windows APIs and common functions like string manipulations, Data structures, stream, IO, thread, security etc.

5. Common Language Specification (CLS): What makes a language to be .Net compliant? Answer is CLS. Microsoft has defined some specifications that each .Net language has to follow. For e.g.: no pointer, no multiple inheritances etc.

6. Common Type System (CTS): CTS defines some basic data types that IL can understand. Each .Net compliant language should map its data types to these standard data types. This makes it possible for two .Net compliant languages to communicate by passing/receiving parameters to and from each other. For example CTS defines Int32 for C# int and VB integer data types.

7. The .Net Framework: Is a combination of CLR, FCL, ADO.Net and XML classes, Web/Window applications and Web services.

 

Common Language Infrastructure (CLI)

The purpose of CLI is to provide a language-neutral platform for application development and execution, including functions for exception handling, garbage collection, security, and interoperability. By implementing the core aspects of .NET Framework within the scope of CLI, this functionality will not be tied to a single language but will be available across the many languages supported by the framework. Microsoft’s implementation of CLI is CLR.

Common Intermediate Language (CIL) code is housed in CLI assemblies. As mandated by the specification, assemblies are stored in Portable Executable (PE) format, common on Windows platform for all DLL and EXE files. The assembly consists of one or more files, one of which must contain the manifest, which has the metadata for the assembly. The complete name of an assembly (not to be confused with the filename on disk) contains its simple text name, version number, culture, and public key token. Assemblies are considered equivalent if they share the same complete name, excluding the revision of the version number. A private key can also be used by the creator of the assembly for strong naming. The public key token identifies which private key an assembly is signed with. Only the creator of the keypair (typically .NET developer signing the assembly) can sign assemblies that have the same strong name as a previous version assembly, since the creator is in possession of the private key. Strong naming is required to add assemblies to Global Assembly Cache.

Security

.NET has its own security mechanism with two general features: Code Access Security (CAS), and validation and verification. CAS is based on evidence that is associated with a specific assembly. Typically the evidence is the source of the assembly (whether it is installed on the local machine or has been downloaded from the intranet or Internet). CAS uses evidence to determine the permissions granted to the code. Other code can demand that calling code be granted a specified permission. The demand causes CLR to perform a call stack walk: every assembly of each method in the call stack is checked for the required permission; if any assembly is not granted the permission a security exception is thrown.

Memory management

CLR frees the developer from the burden of managing memory (allocating and freeing up when done); it handles memory management itself by detecting when memory can be safely freed. Instantiations of .NET types (objects) are allocated from the managed heap; a pool of memory managed by CLR. As long as there exists a reference to an object, which might be either a direct reference to an object or via a graph of objects, the object is considered to be in use. When there is no reference to an object, and it cannot be reached or used, it becomes garbage, eligible for collection. .NET Framework includes a garbage collector which runs periodically, on a separate thread from the application’s thread, that enumerates all the unusable objects and reclaims the memory allocated to them.

 

.NET Garbage Collector (GC) is a non-deterministic, compacting, mark-and-sweep garbage collector. GC runs only when a certain amount of memory has been used or there is enough pressure for memory on the system. Since it is not guaranteed when the conditions to reclaim memory are reached, GC runs are non-deterministic. Each .NET application has a set of roots, which are pointers to objects on the managed heap (managed objects). These include references to static objects and objects defined as local variables or method parameters currently in scope, as well as objects referred to by CPU registers. When GC runs, it pauses the application, and for each object referred to in the root, it recursively enumerates all the objects reachable from the root objects and marks them as reachable. It uses CLI metadata and reflection to discover the objects encapsulated by an object, and then recursively walk them. It then enumerates all the objects on the heap (which were initially allocated contiguously) using reflection. All objects not marked as reachable are garbage. This is the mark phase. Since the memory held by garbage is not of any consequence, it is considered free space. However, this leaves chunks of free space between objects which were initially contiguous. The objects are then compacted together to make used memory contiguous again. Any reference to an object invalidated by moving the object is updated by GC to reflect the new location. The application is resumed after the garbage collection is over.

 

GC used by .NET Framework is also generational. Objects are assigned a generation; newly created objects belong to Generation 0. The objects that survive a garbage collection are tagged as Generation 1, and the Generation 1 objects that survive another collection are Generation 2 objects. .NET Framework uses up to Generation 2 objects. Higher generation objects are garbage collected less frequently than lower generation objects. This helps increase the efficiency of garbage collection, as older objects tend to have a longer lifetime than newer objects. Thus, by eliminating older (and thus more likely to survive a collection) objects from the scope of a collection run, fewer objects need to be checked and compacted.