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
- Compilation of source code to IL
- IL to platform specific code by CLR (machine code)
- Code running under the control of CLR often termed as managed code.
IL
- 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.