What is .Net and Where is ASP.NET? - .NET to the Rescue! (Page 3 of 3 )
Noting these problems, Microsoft set out to correct them with their .NET initiative. For developers, .NET contains two important parts: the Common Language Runtime (CLR) and the .NET Framework classes. These two pieces directly address the three disadvantages we looked at earlier. We will look at these two pieces in detail, and examine their function and purpose.
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 the earlier diagram we have seen 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 interact 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 us take a moment to look back at our three previous disadvantages inherent in a "compile directly from source code to machine code" paradigm.
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 seamlessly 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.
Till now we have observed the two most important parts to .NET: the CLR and the .NET Framework classes. We'll examine how and where ASP.NET fits into the picture!
ASP.NET - Where Does it Fit within .NET?
ASP.NET is Microsoft's next "version" of ASP - it is basically ASP utilizing the .NET factors described in the last two parts of this article. That means that ASP.NET pages need to be created with .NET-compatible languages, which include VB.NET, C#, and JScript.NET.
When an ASP.NET page is visited via a Web browser, the ASP.NET engine first checks to see if there already exists an up-to-date version of the IL code for the ASP.NET page. If there does, this IL is squirted to the CLR, and the HTML output generated by the ASP.NET page is then sent to the client's browser that requested the ASP.NET Web page. If, however, the IL does not exist at all or the ASP.NET page's source code has changed since the last IL was generated, the ASP.NET page must be recompiled. Depending on what language the ASP.NET page was written in, the proper compiler is instantiated and the IL created. This IL is saved on disk so that, for future requests, this recompilation, an expensive process, does not need to recur.
If you've created ASP.NET pages, you most likely aware of the concept of Web controls. These are controls that can be used in an ASP.NET Web page to produce HTML elements like text boxes, labels, list boxes, etc. For example, to create a text box using a Web control, one can do:
<asp:textbox id="Name" runat="server" />
In fact, an ASP.NET Web page can contain a mix of server-side code (in server-side SCRIPT blocks) along with in-line HTML, like:
<script language="VB" runat="Server"> Sub Page_Load(sender as Object, e as EventArgs) lblMessage.Text = "Hello, Welcome to .Net!" End Sub</script> <html><body> <h1>Simple ASP.NET Demo</h1> <asp:label id="lblMessage" runat="server" /> </body></html>
So how does that HTML/server-side code get translated into something that the VB.NET compiler can understand? One of the ASP.NET engine's most important tasks is translating the HTML/server-side code into a class that the VB.NET compiler (or C# or JScript.NET compilers) can understand. This process is a difficult one, and beyond the scope of this article; however, do be aware that your pages are turned into a class that inherits from the Page class (one of the classes in the .NET Framework). In fact, all of the Web controls that you can use in your ASP.NET Web pages are represented as classes in the .NET Framework. Additionally, any ad hoc HTML code in your ASP.NET Web page is captured and represented as an instance of the LiteralText class. Due to these translations, it is no understatement to say that ASP.NET Web pages are, indeed, actual running programs. No longer is a dynamic Web page just some simple script.
I can tell you that ASP.NET is:
1. Way cool, and
2. Way powerful
You can do some really impressive tasks really easily with ASP.NET, tasks that required hundreds of lines of messy code in classic ASP.
Happy Reading and Happy Programming!
DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.