Wednesday, 25 June 2014

What is the Dot NET Framework?

What is the .NET Framework?

The .NET Framework is a new and revolutionary platform created by Microsoft for developing applications. The first release of the .NET Framework runs on the Windows operating system, future plans include versions that will work on others, such as FreeBSD, Linux, Macintosh, and even personal digital assistant (PDA) class devices. One of the key motivational forces behind this technology is its intention as a means of integrating disparate operating systems.

The .NET Framework allows the creation of Windows applications, web applications, web services, and pretty much anything else you can think of.


The .NET Framework has been designed such that it can be used from any language. This includes C#, C++, Visual Basic, JScript, and even older languages such as COBOL. In order for this to work, .NET-specific versions of these languages have also appeared: Managed C++, Visual Basic .NET, JScript .NET, J#, and so on – and more are being released all the time. Not only do all of these have access to the .NET Framework, they can also communicate with each other. It is perfectly possible for C# developers to make use of code written by Visual Basic .NET programmers, and vice versa.
 
What's in the .NET Framework?
 
The .NET Framework consists primarily of a gigantic library of code that we use from our client languages (such as C#) using object-oriented programming (OOP) techniques. This library is categorized into different modules – we use portions of it depending on the results we want to achieve. For example, one module contains the building blocks for Windows applications, another for network programming, and another for web development. Some modules are divided into more specific sub modules, such as a module for building web services within the module for web development.
Part of the .NET Framework library defines some basic types. A type is a representation of data, and specifying some of the most fundamental of these (such as "a 32-bit signed integer") facilitates interoperability between languages using the .NET Framework. This is called the Common Type System (CTS).
As well as supplying this library, the framework also includes the .NET Common Language Runtime (CLR), which is responsible for maintaining the execution of all applications developed using the NET  library.

How do I Write Applications using the .NET Framework?

 
Writing an application using the .NET Framework means writing code (using any of the languages that support the framework) using the .NET code library.
In order for VB.NET code to execute it 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.
 
MSIL and JIT
 
When we compile code that uses the .NET Framework library, we don't immediately create operating system-specific native code. Instead, we compile our code into Microsoft Intermediate Language(MSIL) code. This code isn't specific to any operating system, and isn't specific to Visual Basic .NET. Other .NET languages – for example, c# – also compile to this language as a first stage.
Obviously, in order to execute an application more work is necessary. This is the job of a Just-In-Time (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 here reflects the fact that MSIL code is only compiled as and when it is needed. In the past it has often been necessary to compile your code into several applications, each of which targets a specific operating system and CPU architecture. This is now unnecessary, as JIT compilers (as their name suggests) use MSIL code, which is independent of the machine, operating system, and CPU.
 
 
 
Assemblies

 When we compile an application, the MSIL code created is stored in an assembly. Assemblies include both executable application files that we can run directly from Windows without the need for any other programs (these have a .exe file extension), and libraries for use by other applications (which have a .dll extension).
 
As well as containing MSIL, assemblies also contain 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). This means that deploying applications is often as simple as copying the files into a directory on a remote computer.

It is often useful to place this reusable code in a place accessible to all applications. In the .NET Framework, this is the Global Assembly Cache (GAC). Placing code in this cache is simple – we just place the assembly containing the code in the directory containing this cache.

 Managed Code

The role of the CLR doesn't end once we have compiled our code to MSIL and a JIT compiler has compiled this to native code. Code written using the .NET Framework is managed when it is executed (this stage is usually referred to as being at "runtime"). This means that the CLR looks after our applications, by managing memory, handling security, allowing cross-language debugging, and so on. By contrast, applications that do not run under the control of the CLR are said to be unmanaged.

 Garbage Collection 

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..NET garbage collection works by inspecting the memory of your computer every so often, and removing anything from it that is no longer needed.

 Linking 

There is one additional point to note concerning the above process. The VB.NET code that compiles into MSIL in step 2 needn't be contained in a single file. It is possible to split application code across multiple source code files, which are then compiled together into a single assembly. This process is known as linking, and is extremely useful. The reason for this is that it is far easier to work with several smaller files that one enormous one. You can separate out logically related code into an individual file, so that it can be worked on independently, and then practically forgotten about when completed.

No comments:

Post a Comment