Microsoft .Net Framework

Many people have their own interpretation of the Microsoft .Net framework. Here is my 2 cents on this. We first need to understand that the framework is a collection of assemblies (resource & binary files) that enable us to program.
The framework generally consists of 3 main components:-
1] CLR (Common Language Runtime)
2] FCL (Framework Class Library)
3] ASP.net Runtime
Now the CLR is a vast topic which would probably take me years to document but I feel that the MSDN website gives us a general understanding.



Now if we take a look at the above diagram, you would sort of find yourselves asking one question: Why did I not add in the CTS and CLS as part of the Framework i.e. because the CLR is primarily responsible for the CTS and CLS and I would classify it in the following manner:
1] CLR
--------------------> CTS ----------------------->2
--------------------> CLS ----------------------->2
2] FCL
3]ASP.net runtime
Now a useful concept to understand here is how is our program being executed. Now when it comes to C/C++ we normally know the routine Code --> Compiler --> interpreter --> binary mc instructions Now how does it work in .Net:
We write a code in C# and then the CLR is responsible for knowing which compiler needs to be called (i.e. call the C sharp compiler csc.exe), now once the compiler compiles the code and then sends the pseudocode it generates to the ILasm.exe (Interpreted Language assembler). Now this basically converts the pseudocode to a binary (or we could call it a low level) object oriented language called Interpreted Language or IL for short. But this is not all, the ILasm.exe creates an Assembly called PE32 (32 bit) or PE32+ (64 bit) where the PE stands for Portable Executable. The PE comes with a header, IL and metadata (data on data). The header contains useful info like assembly information, compilation and execution time runs, build timestamps, program location etc.., the IL contains our source code and the Metadata basically contains two tables a] Table1 contains all the members and objects (resources) defined in our source and b] Table2 contains all the members and objects (resources)referenced by our source. A good example to cite here would be:


The FCL is a collection of assemblies or a library of information that contain all the type definitions for the .Net framework. Now I use this cheat sheet for practical purposes ( I am extremely bad with syntax ):




Now the important thing is that all these types are derived from the system.object namespace. Why?? Because it makes it easier to have a single point as a source rather than multiple sources. I feel that this is enough for today, oops I think I fogot to add an important concept here, the CLR bascically interacts with the FCL and tries to find out what method or function is being accessed by the end user. The clr typically associates a location in memory for this. Now once the IL is JITed (Just in time compilation) and the binary instructions are in the memory, the CLR takes this memory location address and places this address in its initial placeholder. Hence everytime you recall this method, there is no overhead of a JIT compilation occuring again. Cool huh!!!!.

Comments

Anonymous said…
Do you have copy writer for so good articles? If so please give me contacts, because this really rocks! :)
Anonymous said…
Not bad article, but I really miss that you didn't express your opinion, but ok you just have different approach

Popular posts from this blog

System.ConfigurationSettings.AppSettings is Obsolete

Branding your SharePoint site in a super fast way - Emgage

Sharepoint & SSRS integration Issues