Published: Friday, May 18, 2001
An Examination of .NET and How and Where ASP.NET Fits In, Part 2
By Scott Mitchell
Read Part 1
In Part 1 we looked at how, classically, high-level programming languages
have translated source code into an executable file. We also looked at three major disadvantages with this
technique. In this part, we'll examine the CLR and the .NET Framework classes, the two parts of Microsoft's
.NET initiative that resolves these problems.
The Common Language Runtime (CLR)
In Part 1 we looked at a diagram
that illustrated how classic compilers convert high-level source code into instructions the computer can understand.
With .NET, this picture changes dramatically. .NET-compatible compilers do not translate source code into Win32
API calls, but rather translate this high-level source code into a special intermediate language, Microsoft
Intermediate Language (MSIL). The CLR, then, takes this intermediate language (IL) and, on the fly, converts it
into machine-specific instructions. A diagram of this process can be seen below:
Realize that the CLR-to-Running Program step only occurs when you execute a program. The compiler creates an
file that contain MSIL. When this is "executed," the MSIL is streamed to the CLR, which then performs just-in-time
(JIT) compilation, converting the IL to instructions the computer can understand. And voila, you have a running
program using the CLR!
The .NET Framework Classes
Recall that prior to .NET, Windows applications utilized the Win32 API, a vast collection of functions that interacted
with the operating system to provide all sorts of tasks (graphical stuff, hardware information/manipulation, and
other OS-level tasks). So how does a .NET program intereact with the operating system? Thankfully the Win32 API
is a thing of the past; .NET applications utilize the .NET Framework classes, a large, organized collection of
classes that allow for all the functionality a developer would ever need.
Unlike the Win32 API, the .NET Framework classes are nicely organized in a hierarchical system of namespaces. Each
namespace can contain an unlimited number of classes. For example, the base namespace, System, contains
classes that are used for the primitive data types: System.Int32, System.Array, System.String,
etc. The System.Data namespace contains classes and namespaces related to data access; the
System.IO namespace contains classes for file manipulation and general input/output. There are literally
hundreds of classes in the .NET Framework, all nicely organized by namespace. In fact, you can easily create
your own classes and namespaces for use in your .NET applications.
Notice that the .NET Framework classes contain a class for each primitive data type in the
System namespace. .NET programming languages (like VB.NET, C#, JScript.NET, etc.) must use these
data types, meaning that each data type is, essentially, a class. So, when you do the following:
In VB.NET: Dim i as Integer
In C#: int i;
In JScript.NET: var i;
|
You are really creating an instance of a class, System.Int32. Since each programming language
uses the same data types and works from the same set of classes, interopability between languages in a snap. There's
a reason the CLR is called the Common Language Runtime - each programming language ends up producing MSIL,
which is guaranteed to use agreed upon data types and work with classes in the .NET Framework.
Addressing the Three Disadvantages
Let's take a moment to look back at our three previous disadvantages inherent in a "compile directly from source code to
machine code" paradigm. In Part 1 we listed those three disadvantages as:
- Platform specific.
- Difficulty in language interoperability.
- Messy structure of the Win32 API.
.NET addresses each of these problems, kind of. The first disadvantage is no longer a problem in theory, only in
reality. That is, in theory Microsoft could port the CLR and .NET Framework classes to any platform and operating
system, meaning the MSIL generated by VisualBasic.NET could be run on a Linux box. In reality, though, Microsoft
has not (yet) made public any such intention of porting the CLR to any other platforms or operating systems.
Personally, I wouldn't be surprised to see such a port eventually.
The language interoperability issue is directly addressed by the .NET Framework including classes for both
primitive data types and functions for working at the OS-level. By requiring programming languages to use the
classes in the .NET Framework, you can create IL that any .NET-compatible programming language can seemlessly use!
Also, the .NET Framework is constructed entirely of classes, and these classes are arranged into a hierarchy,
making them much easier to discover, use, and understand than their Win32 API counterparts.
In Part 3 we'll look at where ASP.NET fits into this entire picture.
Read Part 3!
