Seven Important Facts About ASPNET
If you're new to ASP.NET (or you just want to review a few fundamentals), you'll be interested in the following sections. They introduce seven touchstones of .NET development.
Fact 1: ASP.NET Is Integrated with the .NET Framework
The .NET Framework is divided into an almost painstaking collection of functional parts, with a staggering total of more than 40,000 types (the .NET term for classes, structures, interfaces, and other core programming ingredients). Before you can program any type of .NET application, you need a basic understanding of those parts—and an understanding of why things are organized the way they are.
The massive collection of functionality that the .NET Framework provides is organized in a way that traditional Windows programmers will see as a happy improvement. Each one of the thousands of classes in the .NET Framework is grouped into a logical, hierarchical container called a namespace. Different namespaces provide different features. Taken together, the .NET namespaces offer functionality for nearly every aspect of distributed development from message queuing to security. This massive toolkit is called the class library.
Interestingly, the way you use the .NET Framework classes in ASP.NET is the same as the way you use them in any other type of .NET application (including a stand-alone Windows application, a Windows service, a command-line utility, and so on). In other words, .NET gives the same tools to web developers that it gives to rich client developers.
■rip One of the best resources for learning about new corners of the .NET Framework is the .NET Framework class library reference, which is part of the MSDN Help library reference. If you have Visual Studio 2008 installed, you can view the MSDN Help library by selecting Start > Programs > Microsoft Visual Studio 2008 > Microsoft Visual Studio 2008 Documentation (the exact shortcut depends on your version of Visual Studio). Once you've loaded the help, you can find class reference information grouped by namespace under the .NET Development > .NET Framework SDK > .NET Framework > .NET Framework Class Library node.
Fact 2: ASP.NET Is Compiled, Not Interpreted
One of the major reasons for performance degradation in classic ASP pages is its use of interpreted script code. Every time an ASP page is executed, a scripting host on the web server needs to interpret the script code and translate it to lower-level machine code, line by line. This process is notoriously slow.
■ Note In fact, in this case the reputation is a little worse than the reality. Interpreted code is certainly slower than compiled code, but the performance hit isn't so significant that you can't build a professional website using old-style ASP.
ASP.NET applications are always compiled—in fact, it's impossible to execute C# or Visual Basic code without it being compiled first.
ASP.NET applications actually go through two stages of compilation. In the first stage, the C# code you write is compiled into an intermediate language called Microsoft Intermediate Language (MSIL), or just IL. This first step is the fundamental reason that .NET can be language-interdependent. Essentially, all .NET languages (including C#, Visual Basic, and many more) are compiled into virtually identical IL code. This first compilation step may happen automatically when the page is first requested, or you can perform it in advance (a process known as precompiling). The compiled file with IL code is an assembly.
The second level of compilation happens just before the page is actually executed. At this point, the IL code is compiled into low-level native machine code. This stage is known as just-in-time (JIT) compilation, and it takes place in the same way for all .NET applications (including Windows applications, for example). Figure 1-1 shows this two-step compilation process.
- Figure 1-1. Compilation in anASP.NETweb page
.NET compilation is decoupled into two steps in order to offer developers the most convenience and the best portability. Before a compiler can create low-level machine code, it needs to know what type of operating system and hardware platform the application will run on (for example, 32-bit or 64-bit Windows). By having two compile stages, you can create a compiled assembly with .NET code and still distribute this to more than one platform.
Of course, JIT compilation probably wouldn't be that useful if it needed to be performed every time a user requested a web page from your site. Fortunately, ASP.NET applications don't need to be compiled every time a web page is requested. Instead, the IL code is created once and regenerated only when the source is modified. Similarly, the native machine code files are cached in a system directory that has a path like c:\Windows\Microsoft.NET\ Framework\v2.0.50727\Temporary ASP.NET Files.
■ Note You might wonder why the temporary ASP.NET files are found in a directory with a 2.0 version number rather than a 3.5 version number. Technically, ASP.NET 3.5 uses the ASP.NET 2.0 engine (with a few new features piled on). You'll learn more about this design later in the chapter, in the "ASP.NET 3.5: The Story Continues" section.
As you'll learn in Chapter 2, the actual point where your code is compiled to IL depends on how you're creating and deploying your web application. If you're building a Web Application project in Visual Studio, the code is compiled to IL when you compile your project. But if you're building a lighter-weight projectless Web Site project, the code for each page is compiled the first time you request that page. Either way, the code goes through its second compilation step (from IL to machine code) the first time it's executed.
ASP.NET also includes precompilation tools that you can use to compile your application right down to machine code once you've deployed it to the production web server. This allows you to avoid the overhead of first-time compilation when you deploy a finished application (and prevent other people from tampering with your code). Precompilation is described in Chapter 19.
■ Note Although benchmarks are often controversial, you can find a few interesting comparisons of Java and ASP.NET at http://msdn2.microsoft.com/en-us/vstudio/aa700836.aspx. Keep in mind that the real issues limiting performance are usually related to specific bottlenecks, such as disk access, CPU use, network bandwidth, and so on. In many benchmarks, ASP.NET outperforms other solutions because of its support for performance-enhancing platform features such as caching, not because of the speed boost that results from compiled code.
Fact 3: ASP.NET Is Multilanguage
Though you'll probably opt to use one language over another when you develop an application, that choice won't determine what you can accomplish with your web applications. That's because no matter what language you use, the code is compiled into IL.
IL is a stepping stone for every managed application. (A managed application is any application that's written for .NET and executes inside the managed environment of the CLR.) In a sense, IL is the language of .NET, and it's the only language that the CLR recognizes.
To understand IL, it helps to consider a simple example. Take a look at this code written in VB .NET:
Imports System Namespace HelloWorld
Public Class TestClass
Public Shared Sub Main()
'Private Sub Main(ByVal args() As String) Console.Writel_ine("Hello World") End Sub End Class End Namespace
This code shows the most basic application that's possible in .NET—a simple command-line utility that displays a single, predictable message on the console window. Now look at it from a different perspective. Here's the IL code for the Main() method:
.method public static void Main() cil managed {
.entrypoint custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 ) II Code size 14 (Oxe)
.maxstack 8 IL_0000: nop
IL_0001: ldstr "Hello World"
IL_0006: call void [mscorlib]System.Console::WriteLine(string)
IL_000b: nop IL_000c: nop IL_000d: ret } II end of method TestClass::Main
It's easy enough to look at the IL for any compiled .NET application. You simply need to run the IL Disassembler, which is installed with Visual Studio and the .NET SDK (software development kit). Look for the file ildasm.exe in a directory like C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin. Once you've loaded the program, use the File > Open command, and select any DLL or EXE that was created with .NET.
■rip For even more disassembling power, check out the remarkable (and free) Reflector tool at http:// www.aisto.com/roeder/dotnet. With the help of community-created add-ins, you can use Reflector to diagram, analyze, and decompile the IL code in any assembly.
If you're patient and a little logical, you can deconstruct the IL code fairly easily and figure out what's happening. The fact that IL is so easy to disassemble can raise privacy and code control issues, but these issues usually aren't of any concern to ASP.NET developers. That's because all ASP.NET code is stored and executed on the server. Because the client never receives the compiled code file, the client has no opportunity to decompile it. If it is a concern, consider using an obfuscator that scrambles code to try to make it more difficult to understand. (For example, an obfuscator might rename all variables to have generic, meaningless names such as f_a_234.) Visual Studio includes a scaled-down version of one popular obfus-
cator, called Dotfuscator.
The following code shows the same console application in C# code:
using System;
namespace HelloWorld {
public class TestClass {
private static void Main(string[] args) {
Console.Writel_ine("Hello World");
If you compile this application and look at the IL code, you'll find that it's nearly identical to the IL code generated from the VB .NET version. Although different compilers can sometimes introduce their own optimizations, as a general rule of thumb no .NET language outperforms any other .NET language, because they all share the same common infrastructure. This infrastructure is formalized in the CLS (Common Language Specification), which is described in the following sidebar, entitled "The Common Language Specification."
It's worth noting that IL has been adopted as an Ecma and ISO standard. This adoption could quite possibly spur the adoption of other common language frameworks on other platforms. The Mono project at http://www.mono-project.com is an example of one such project.
Post a comment