An Examination of .NET and How and Where ASP.NET Fits In

For More Informaion on ASP.NET
For more information on ASP.NET and .NET technologies, be sure to check out the ASP.NET Article Index.

Introduction
At the July 2000 PDC (Professional Developer's Conference), Microsoft unveiled it's .NET initiative. What is .NET, though? If you check out Microsoft's .NET Page, it is described as "Microsoft's platform for XML Web services." Microsoft also describes .NET as a way of delivering software services. However, these pitches are just looking at one tiny facet of .NET, and looking at it from a business or corporate perspective. For developers, .NET is an entirely new design paradigm. In this article we will examine this new paradigm in easy-to-understand terms and we'll look at how ASP.NET fits in!

Back in my Day...
Stop for a moment and ask yourself how computer programs work, exactly. How does the code you write in a VisualBasic application go from that high-level programming code (i.e., MsgBox "Hello, World!") to an actual running program? Classically, this has been accomplished via a compiler, which is a special program that translates the source code into a machine-specific language, such as assembly code (which is then transformed into machine code, an even lower-level language.) Assembly code and machine code, though, are very platform specific. That is, machine code written for an Intel Pentium chip won't run on any machines such as Macintoshes (more generically, they won't run on a machine that uses microprocessor whose instruction set is different that that of Intel's microprocessor's instruction set).

Programs written for Windows are compiled down directly into machine code; rather, they are translated to use the Win32 libraries, which are a set of hundreds of Windows-specific functions. These functions communicate directly with Windows, which in turn knows how to communicate with the lower-level hardware. So when you write a VisualBasic program that simply displays a messagebox, this entire process doesn't begin until you compile the project (Make an Executable). Once this process in complete, you will have an executable file (.exe), which can be run on any Windows box by simply double-clicking the icon - VisualBasic is not needed. In essence, the VisualBasic compiler has turned your high-level instructions into something the Windows operating system can understand, which, in turn, is translated down into instructions the actual computer can understand.

Whew! That's a lot of work. Thankfully, all of those translations are hidden from you, the developer. You can concentrate on simply writing your programs using your high-level language of choice. It is then the compiler's job to do all of the necessary translations, resulting in a final executable file.

There are, however, some fundamental problems with this approach:

1. First, it is very platform specific, meaning that when you write a program using VisualBasic it will only run on computers that use Microsoft Windows.
   
2. Second, there is no guarantee that any two executable programs written in different programming languages will contain similar low-level code, making it next to impossible for disparate programming languages to share libraries of functions. (On an aside, Microsoft's attempt at making a single, common object model using COM has failed in certain respects; if you've ever tried to use COM objects created in VB with COM objects created in Visual C++ you'll have noted that there are oftentimes issues when passing parameters between a COM component written in a different programming language.)
   
3. Thirdly, the Win32 APIs are nothing more than a slew of functions. These functions contain cryptic descriptions and calling parameters. Since there are times in a VB or Visual C++ program where you may wish to call a Win32 API function directly, finding the right Win32 API function call you need to make can be a pain.

The second problem is one of the most profound as programs become more advanced. Ideally, we'd like to be able to share any function libraries or components written in one language with another seemlessly. This task is exasperated due to the fact that different programming languages may define primitive data types differently. For example, VisualBasic allows developers to create arrays with any lower bound, whereas Visual C++ forces arrays to have a lower bound of zero.

.NET to the Rescue!
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. In Part 2 we will look at these two pieces in detail, and examine their function and purpose.