Dot net framework and architecture
Dot net
framework
A programming infrastructure created by
Microsoft for building, deploying, and
running applications and services that use .NET
technologies, such as desktop applications and Web services. The .NET Framework
is a new and revolutionary platform created by Microsoft for developing
- It is a platform for application development .
- It supports Multiple Language and Cross language integration.
- IT has IDE (Integrated Development Environment).
- Framework is a set of utilities or can say building blocks of your application system.
- .NET Framework provides GUI in a GUI manner.
- .NET is a platform independent but with help of Mono Compilation System (MCS). MCS is a middle level interface.
- .NET Framework provides interoperability between languages i.e. Common Type System(CTS) .
- .NET Framework also includes the .NET Common Language Runtime (CLR), which is
- responsible for maintaining the execution of all applications developed using the .NET library.
- The .NET Framework consists primarily of a gigantic library of code.
Cross Language integration
You can use a utility of a language in another language (It uses
Class Language Integration).
.NET Framework
includes no restriction on the type of applications that are possible.
The .NET Framework
allows the creation of Windows applications, Web applications, Web services,
and lot more.The .NET Framework has been designed so that it can be used from
any language, including C#,C++ ,
JScript, and COBOL.
Architecture of CLR
Code Manager
.NET supports two kind of coding
1) Managed Code
2) Unmanaged Code
1.
Managed Code
The resource, which is with in your application
domain is, managed code. The resources that are within domain are faster. The
code, which is developed in .NET framework, is known as manage code. This code
is directly executed by CLR with help of managed code execution. Any language
that is written in .NET Framework is managed code.
Managed code uses CLR which in turns looks
after your applications by managing memory, handling security, allowing cross
language
debugging.
2-Unmanaged Code
The code, which is developed outside .NET,
Framework is known as unmanaged code.
Applications that do not run under the
control of the CLR are said to be unmanaged, and certain languages such as C++
can be used to write such applications, which, for example, access low level
functions of the operating system. Background compatibility with code of VB,
and COM are examples of unmanaged code. Unmanaged code can be unmanaged source
code and unmanaged compile code.Unmanaged code is executed with help of wrapper
classes.
Wrapper classes are of two types: CCW
(COM callable wrapper) and RCW (Runtime Callable Wrapper).Wrapper is used to
cover difference with the help of CCW and RCW. COM callable wrapper unmanaged
code
Native Code
The code to be executed must be converted into
a language that the target operating system understands, known as native code.
This conversion is called compiling code, an act that is performed by a
compiler. Under the .NET Framework, however, this is a two stage process. With
help of MSIL and JIT.
MSIL (Microsoft Intermediate Language)
It is language independent code. When you
compile code that uses the .NET Framework library, you don't immediately create
operating system specific native code. Instead, you compile your code into
Microsoft Intermediate Language (MSIL) code. The MSIL code
is not specific to any operating system or to
any language.
JIT (Just inTime)
Just inTime (JIT) compiler, which compiles MSIL
into native code that is specific to the OS and machine architecture being
targeted. Only at this point can the OS execute the application. The just in time
part of the name reflects the fact that MSIL code is only compiled as, and
when, it
is needed.In the past, it was often necessary
to compile your code into several applications, each of which targeted a
specific operating system and CPU architecture. Often, this was a form of
optimization.This is now unnecessary, because JIT compilers (as their name
suggests) use MSIL code, which is independent of the machine, operating system,
and CPU. Several JIT compilers exist, each targeting a different architecture,
and the appropriate one will be used to create the native code required.The
beauty of all this is that it requires a lot less work on your part in
fact, you can forget about system dependent details
and concentrate on the more interesting functionality of your code.
JIT are
of three types:
1.
Pre JIT
2.
Econo JIT
3.
Normal JIT
Pre JIT
It converts all the code in executable code and
it is slow
Econo JIT
It will convert the called executable code
only. But it will convert code every time when a code is called again.
Normal JIT
It will only convert the called code and will
store in cache so that it will not require converting code again. Normal JIT is
fast. Assemblies
When you compile an application, the MSIL code
created is stored in an assembly. Assemblies include both executable application
files that you can run directly from Windows without the need
for any other programs (these have a .exe file
extension), and libraries (which have a .dll extension) for use by other
applications.
In addition to containing MSIL, assemblies also
include meta information (that is, information about the information contained
in the assembly, also known as metadata) and optional resources(additional data
used by the MSIL, such as sound files and pictures).The meta information
enables assemblies to be fully self descriptive.
You need no other information to use an
assembly, meaning you avoid situations such as failing to add required data to
the system registry and so on, which was often a problem when developing with
other
platforms.
This means that deploying applications is often
as simple as copying the files into a directory on a remote computer. Because
no additional information is required on the target systems, you can just run
an executable file from this directory and (assuming the .NET CLR is installed)
you're good to go.
Of course, you won't necessarily want to
include everything required to run an application in one place. You might write
some code that performs tasks required by multiple applications. In situations
like that, it is often useful to place the reusable code in a place accessible
to all applications. In the .NET Framework, this is the Global Assembly Cache
(GAC). Placing code in the GAC is simple you just place the assembly containing
the code in the directory containing this
cache.
Garbage Collection (GC)
One of the most important features of managed
code is the concept of garbage collection. This is the .NET method of making
sure that the memory used by an application is freed up completely when the
application is no longer in use. Prior to .NET this was mostly the
responsibility of programmers, and a few simple errors in code could result in
large blocks of memory mysteriously disappearing as a result of being allocated
to the wrong place in memory. That usually meant a progressive slowdown of your
computer followed by a system crash. .NET garbage collection works by
inspecting the memory of your computer every so often and removing anything
from it that is no longer needed. There is no set time frame for this; it might
happen thousands of times a second, once every few seconds, or whenever, but
you can rest assured that it will happen.
DLL Hell
"DLL Hell" refers to the set of
problems caused when multiple applications attempt to share a common component
like a dynamic link library (DLL) or a Component Object Model (COM) class. The
reason for this issue was that the version information about the different
components of an application was not recorded by the system. (Windows Registry
cannot support the multiple versions of same COM component this is called the
dll hell problem.) .Net Framework provides with a Global Assembly Cache (GAC).
This Cache is a repository for all the .Net components that are shared globally
on a particular machine. When a .Net component is installed onto the machine,
the Global Assembly Cache looks at its version, its public key, and its
language information and creates a strong name for the component. The component
is then registered in the repository and indexed by its strong name, so there
is no confusion between different versions of the same component, or DLL.
