Points to remember about .Net

This article will give you some tips about .Net. This could be helpful for you especially when you prepare for interviews.

I am just trying to give the brief introduction of .NET framework here in following points:

CLR
IL
JIT
CTS
Garbage collector
AppDomains

CLR

Central to the .net framework is its runtime execution environment, known as CLR.
Compilation occurs in two steps in .net
1. Compilation of source code to IL
2. IL to platform specific code by CLR (machine code)
Code running under the control of CLR often termed as managed code.

Working with .Net means compiling to IL
Any language that targets IL, should logically need to support the main characteristics of IL
By compiling to IL we get platform independence for .net
IL is always Just-In-Time compiled (JIT)

JIT

JIT compiler simply compiles each part of code as it is compiled
When the code has been compiled once, the resultant native executable is stored until the application ends.
JIT can optimize the code for the particular processor the code is running on.
The c# code will be compiled to IL before it is executed (csc compiles only to managed code).

CTS

CTS define the predefined data types that are available in IL, so that all languages that targets .Net Framework compiled codes.
Vb.net - Integer and C# - int both refers to Int32 due to CTS

Garbage collector

GC works in non-deterministic pattern
GC is .Net's answer for memory management
GC takes care of memory leaks
Memory leak can be defined as existence of memory even if the application ends.
COM component maintains a reference count of how many clients are currently maintaining references to it. When the count comes to 0, the memory will be reclaimed.
All dynamically requested memory will be allocated on the heap.
The responsibility of GC is to clean up the unwanted heap memory.
CLR maintains its own heap for .Net applications to use.
Any objects that are not referred to be no longer used in your code will be removed.
It is not possible to use GC with Unmanaged code (like C++)

AppDomains

Appdomains are designed to ease the overhead involved while running applications that need to be isolated each other, but still wants to communicate with each other.
Earlier days, the choice is allowing the instances to share a process. The risk is, if a problem occurs in one running application, it will bring the whole website down.
When you start an application, it will run within the context of a process.
Windows isolates processes from each other through address locations.
4GB of memory will be available for a process running on 32-bit systems.
It is impossible for one process to access memory allocated for another process.
This ensures that any badly behaved code will not affect others.
Each process has its own security token, which indicates to windows precisely what operations that process is permitted to do.
Note that, because processes cannot share memory, a complex marshalling process has to be used to copy data between processes. This signifies a big performance hit.
Appdomains are designed as a way that components are separated without making any performance issues, but still would be able to communicate each other without any hiccups.
The idea is splitting one process into different Appdomains.
The strong type safety of IL ensures that the memory is not handled inappropriately.
If a running application does need to communicate or share data with other application (across Appdomains) it must do so by calling .Net's remoting services.
Code that has been verified to check, that it cannot access data outside its Appdomain (other than through remoting mechanism) is said to be memory-type-safe. Such codes are allowed to run alongside in different Appdomains within the same process.