……………………………………………….Expertise in .NET Technologies

Seven Important Facts about ASP.NET

Posted by Ravi Varma Thumati on July 15, 2009

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 7,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. If you’ve programmed extensively with ASP.NET 1.x, you’ll find that the same set of classes is available in ASP.NET 2.0. The difference is that ASP.NET 2.0 adds even more classes to the mix, many in entirely new namespaces for features such as configuration, health monitoring, and personalization.

Fact 2: ASP.NET Is Compiled, Not Interpreted

One of the major reasons for performance degradation in ASP scripts is that all ASP web-page code uses interpreted scripting languages. This means that when your application is executed, a scripting host on the server machine needs to interpret your code and translate it to lower-level machine code, line by line. This process is notoriously slow.

ASP.NET applications are always compiled—in fact, it’s impossible to execute C# or VB .NET 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) code, or just IL. This first step is the fundamental reason that .NET can be languageinterdependent. 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.


.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 but 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 or web service 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:\[WinDir]\Microsoft.NET\Framework\ [Version]\Temporary ASP.NET Files, where [WinDir] in the Windows directory and [Version] is the version number for the currently installed version of the .NET Framework.

Although the compilation model in ASP.NET 2.0 remains essentially the same, it has one important change. The design tool (Visual Studio) no longer compiles code. Instead, your web pages and services are compiled the first time you run them, which improves the debugging experience.

To avoid the overhead of first-time compilation when you deploy a finished application (and prevent other people from tampering with your code), you can use a new precompilation feature, which is explained in Chapter 18.

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 function, written in C#:

namespace HelloWorld


public class TestClass


private static void Main(string[] args)


Console.WriteLine(“Hello World”);




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 same class:

.method public static void Main() cil managed



.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() =

( 01 00 00 00 )

// Code size 14 (0xe)

.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

} // end of method Module1::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\Visual Studio 2005\SDK\v2.0\Bin. Once you’ve loaded the program, use the File ➤Open command, and select any DLL or EXE that was created with .NET.

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 obfuscator, called Dotfuscator.

The following code shows the same console application in Visual Basic code:

Namespace HelloWorld

Public Class TestClass

Private Shared Sub Main(Ars() As String)

Console.WriteLine(“Hello World”)

End Sub

End Class

End Namespace

If you compile this application and look at the IL code, you’ll find that every line is identical to the IL code generated from the C# 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 “The Common Language Specification” sidebar.

It’s important to note that IL was recently adopted as an ANSI (American National Standards nstitute) standard. This adoption could quite possibly spur the adoption of other common language frameworks. The Mono project at is an example of one such project.


The CLS defines the standard properties that all objects must contain in order to communicate with one another in a homogenous environment. To allow this communication, the CLR expects all objects to adhere to a specific set of rules.

The CLS is this set of rules. It defines many laws that all languages must follow, such as keywords, types, primitive types, method overloading, and so on. Any compiler that generates IL code to be executed in the CLR must adhere to all rules governed within the CLS. The CLS gives developers, vendors, and software manufacturers the opportunity to work within a common set of specifications for languages, compilers, and data types. As time goes on, you’ll see more CLS-compliant languages and compilers emerge, although several are available so far.

Given these criteria, the creation of a language compiler that generates true CLR-compliant code can be complex. Nevertheless, compilers can exist for virtually any language, and chances are that there may eventually be one for just about every language you’d ever want to use. Imagine—mainframe programmers who loved COBOL in its heyday can now use their knowledge base to create web applications!

Fact 4: ASP.NET Runs inside the Common Language Runtime

Perhaps the most important aspect of ASP.NET to remember is that it runs inside the runtime engine of the CLR. The whole of the .NET Framework—that is, all namespaces, applications, and classes—are referred to as managed code. Though a full-blown investigation of the CLR is beyond the scope of this chapter, some of the benefits are as follows:

Automatic memory management and garbage collection: Every time your application instantiates an object, the CLR allocates space on the managed heap for that object. However, you never need to clear this memory manually. As soon as your reference to an object goes out of scope (or your application ends), the object becomes available for garbage collection. The garbage collector runs periodically inside the CLR, automatically reclaiming unused memory for inaccessible objects. This model saves you from the low-level complexities of C++ memory handling and from the quirkiness of COM reference counting.

Type safety: When you compile an application, .NET adds information to your assembly that indicates details such as the available classes, their members, their data types, and so on. As a result, your compiled code assemblies are completely self-sufficient. Other people can use them without requiring any other support files, and the compiler can verify that every call is valid at runtime. This extra layer of safety completely obliterates low-level errors such as the infamous buffer overflow.

Extensible metadata: The information about classes and members is only one of the types of metadata that .NET stores in a compiled assembly. Metadata describes your code and allows you to provide additional information to the runtime or other services. For example, this metadata might tell a debugger how to trace your code, or it might tell Visual Studio how to display a custom control at design time. You could also use metadata to enable other runtime services (such as web methods or COM+ services).

Structured error handling: If you’ve ever written any moderately useful Visual Basic or VBScript code, you’ll most likely be familiar with the limited resources these languages offer for error handling. With structured exception handling, you can organize your error-handling code logically and concisely. You can create separate blocks to deal with different types of errors. You can also nest exception handlers multiple layers deep.

Multithreading: The CLR provides a pool of threads that various classes can use. For example, you can call methods, read files, or communicate with web services asynchronously, without


Figure 1-2. The CLR and .NET Framework

Fact 5: ASP.NET Is Object-Oriented

ASP provides a relatively feeble object model. It provides a small set of objects; these objects are really just a thin layer over the raw details of HTTP and HTML. On the other hand, ASP.NET is truly object-oriented. Not only does your code have full access to all objects in the .NET Framework, but you can also exploit all the conventions of an OOP (object-oriented programming) environment.

For example, you can create reusable classes, standardize code with interfaces, and bundle useful

functionality in a distributable, compiled component. One of the best examples of object-oriented thinking in ASP.NET is found in server-based controls. Server-based controls are the epitome of encapsulation. Developers can manipulate control objects programmatically using code to customize their appearance, provide data to display, and even react to events. The low-level HTML details are hidden away behind the scenes. Instead of forcing the developer to write raw HTML manually, the control objects render themselves to HTML when the page is finished rendering. In this way, ASP.NET offers server controls as a way to abstract

Here’s a quick example with a standard HTML text box:

<input runat=”server” />

With the addition of the runat=”server” attribute, this static piece of HTML becomes a fully functional server-side control that you can manipulate in your code. You can now work with events that it generates, set attributes, and bind it to a data source.

For example, you can set the text of this box when the page first loads using the following code:

void Page_Load(object sender, EventArgs e)


myText.Value = “Hello World!”;


Technically, this code sets the Value property of an HtmlInputText object. The end result is that a string of text appears in a text box on the HTML page that’s rendered and sent to the client.


When ASP.NET was first created, two schools of thought existed. Some ASP.NET developers were most interested in server-side controls that matched the existing set of HTML controls exactly. This approach allows you to create ASP.NET web-page interfaces in dedicated HTML editors, and it provides a quick migration path for existing ASP pages. However, another set of ASP.NET developers saw the promise of something more—rich server-side controls that didn’t just emulate individual HTML tags. These controls might render their interface from dozens of distinct HTML elements while still providing a simple object-based interface to the programmer. Using this model, developers could work with programmable menus, calendars, data lists, and validators.

After some deliberation, Microsoft decided to provide both models. You’ve already seen an example of HTML server controls, which map directly to the basic set of HTML tags. Along with these are ASP.NET web controls, which provide a higher level of abstraction and more functionality. In most cases, you’ll use HTML server-side controls for backward compatibility and quick migration and use web controls for new projects.

ASP.NET web control tags always start with the prefix asp: followed by the class name. For example, the following snippet creates a text box and a check box:

<asp:TextBox Text=”Hello ASP.NET TextBox” runat=”server” />

<asp:CheckBox Text=”My CheckBox” runat=”server” />

Again, you can interact with these controls in your code, as follows:

myASPText.Text = “New text”; myASPCheck.Text = “Check me!”;

Notice that the Value property you saw with the HTML control has been replaced with a Text property.

The HtmlInputText.Value property was named to match the underlying value attribute in the HTML <input> tag. However, web controls don’t place the same emphasis on correlating with HTML syntax, so the more descriptive property name Text is used instead.

The ASP.NET family of web controls includes complex rendered controls (such as the Calendar and TreeView), along with more streamlined controls (such as TextBox, Label, and Button), which map closely to existing HTML tags. In the latter case, the HTML server-side control and the ASP.NET web control variants provide similar functionality, although the web controls tend to expose a more standardized, streamlined interface. This makes the web controls easy to learn, and it also means they’re a natural fit for Windows developers moving to the world of the Web, because many of the property names are similar to the corresponding Windows controls.

Fact 6: ASP.NET Is Multidevice and Multibrowser

One of the greatest challenges web developers face is the wide variety of browsers they need to support. Different browsers, versions, and configurations differ in their support of HTML. Web developers need to choose whether they should render their content according to HTML 3.2, HTML 4.0, or something else entirely—such as XHTML 1.0 or even WML (Wireless Markup Language) for mobile devices. This problem, fueled by the various browser companies, has plagued developers since the World Wide Web Consortium proposed the first version of HTML. Life gets even more complicated if you want to use an HTML extension such as JavaScript to create a more dynamic page or provide validation.

ASP.NET addresses this problem in a remarkably intelligent way. Although you can retrieve information about the client browser and its capabilities in an ASP.NET page, ASP.NET actually encourages developers to ignore these considerations and use a rich suite of web server controls. These server controls render their HTML adaptively by taking the client’s capabilities into account. One example is ASP.NET’s validation controls, which use JavaScript and DHTML (Dynamic HTML) to enhance their behavior if the client supports it. This allows the validation controls to show dynamic error messages without the user needing to send the page back to the server for more processing.

These features are optional, but they demonstrate how intelligent controls can make the most of cutting-edge browsers without shutting out other clients. Best of all, you don’t need any extra coding work to support both types of client.

Fact 7: ASP.NET Is Easy to Deploy and Configure

One of the biggest headaches a web developer faces during a development cycle is deploying a completed application to a production server. Not only do the web-page files, databases, and components need to be transferred, but you also need to register components and re-create a slew of configuration settings. ASP.NET simplifies this process considerably. Every installation of the .NET Framework provides the same core classes. As a result, deploying an ASP.NET application is relatively simple. In most cases, you simply need to copy all the files to a virtual directory on a production server (using an FTP program or even a command-line command like XCOPY). As long as the host machine has the .NET Framework, there are no time-consuming registration steps.

Distributing the components your application uses is just as easy. All you need to do is copy the component assemblies when you deploy your web application. Because all the information about your component is stored directly in the assembly file metadata, there’s no need to launch a registration program or modify the Windows registry. As long as you place these components in the correct place (the Bin subdirectory of the web application directory), the ASP.NET engine automatically detects them and makes them available to your web-page code. Try that with a traditional COM component!

Configuration is another challenge with application deployment, particularly if you need to transfer security information such as user accounts and user privileges. ASP.NET makes this deployment process easier by minimizing the dependence on settings in IIS (Internet Information Services). Instead, most ASP.NET settings are stored in a dedicated web.config file. The web.config file is placed in the same directory as your web pages. It contains a hierarchical grouping of application settings stored in an easily readable XML format that you can edit using nothing more than a text editor such as Notepad. When you modify an application setting, ASP.NET notices that change and smoothly restarts the application in a new application domain (keeping the existing application domain alive long enough to finish processing any outstanding requests). The web.config file is never locked, so it can be updated at any time.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: