The crux of the CLR is physically represented by a library named mscoree.dll (a.k.a. the common Object Runtime Execution Engine). When an assembly is referenced for use, mscoree.dll isloaded automatically, which in turn loads the required assembly into memory. The runtime engine is responsible for a number of tasks.

First and foremost, it is the entity in charge of resolving the location of an assembly and finding the requested type within the binary by reading the contained metadata. The CLR then lays out the type in memory, compiles the associated CIL into platformspecific instructions, performs any necessary security checks, and then executes the code in question.

In addition to loading your custom assemblies and creating your custom types, the CLR will also interact with the types contained within the .NET base class libraries when required. Although the entire base class library has been broken into a number of discrete assemblies, the key assembly is mscorlib.dll. mscorlib.dll contains a large number of core types that encapsulate a wide variety of common programming tasks as well as the core data types used by all .NET languages.

When you build .NET solutions, you automatically have access to this particular assembly.

The below Figure illustrates the workflow that takes place between your source code (which is making use of base class library types), a given .NET compiler, and the .NET execution engine.

The previous post in this blog is regarding software testing interview questions and you can have a quick look about that at here.

No comments:

Post a Comment