When you think ASP, think...
Recent Articles
All Articles
ASP.NET Articles
ASPFAQs.com
Message Board
Related Web Technologies
User Tips!
Coding Tips

Sections:
Sample Chapters
Commonly Asked Message Board Questions
JavaScript Tutorials
MSDN Communities Hub
Official Docs
Security
Stump the SQL Guru!
XML Info
Information:
Feedback
Author an Article
ASP ASP.NET ASP FAQs Message Board Feedback
Print this page.
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.

    - continued -

    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:

    A program is compiled into IL and interpretted by the CLR.

    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:

    1. Platform specific.
    2. Difficulty in language interoperability.
    3. 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!


  • ASP.NET [1.x] [2.0] | ASPMessageboard.com | ASPFAQs.com | Advertise | Feedback | Author an Article