Introducing ASP.NET

I l @ ve RuBoard

The creation of Web-based interfaces and their associated functionality accounts for a major part of most application development. One reason that HTML became so popular was its simplicity ” anyone with a text editor could create their own Web pages. HTML works fine for static Web content, but in an application that will use Web pages for its user interface, the Web pages must interact with the application functionality and their content must change to display application data to the user . Such Web pages must contain some executable content to interact with the main application code, in addition to fixed HTML. Few people can create such Web pages using just a text editor ”and even fewer would choose to do so.

A Web-based application runs in a specific context:

• The client interacts with the server using a request-response protocol.

• The client typically sends request information in text format, such as name /value pairs or tagged data.

• The server typically sends response information in text format, such as tagged data.

This description is intentionally generic ”the Web means different things to different people. However, for most people the Web is synonymous with browser-based applications and content.

Browser-Based Web Applications

This chapter focuses on developing systems in which the client is assumed to be a Web browser. (The next two chapters will cover Web services, in which client applications can be almost any type of executable program.)

The context in which a browser-based application operates has the following characteristics:

• The client sends HTTP requests to the server. The HTTP request header contains some standard information that might be of use to the application developer. Other information from the client can be encoded as part of the URL used to access the server component (using HTTP GET requests), or it can be sent in the body of the request (using HTTP POST requests).

• The server processes the client request and generates output consisting mainly of HTML. Information can also be sent by embedding some XML in the output and by setting certain fields in the HTTP response header.

Although these two characteristics are required, many variables remain . The browser might be Microsoft Internet Explorer, Netscape Navigator, or Opera, for example. Even if your application is targeted at an intranet environment in which only Internet Explorer is used, you must still address the issue of handling the different levels of functionality available in different versions. As a Web application developer, you must typically make a decision about reach versus richness. In other words, should you develop a very functional application that can run only in Internet Explorer 5.5 and later, or should you create an application with a simpler interface and less functionality that can run on almost any browser? It's difficult to create an application that can adapt to the type of client and provide an appropriate level of richness. However, as you'll see, ASP.NET Web controls can help an application adapt to different clients and still deliver a rich user interface.

The ASP.NET Environment

An ASP.NET application, like its ASP predecessor, runs using Microsoft Internet Information Services (IIS). The files that make up an ASP.NET application reside in a virtual directory configured under IIS. An example of such a virtual directory is http://www.fourthcoffee.com/FourthCoffee . Typically, this directory is mapped to a folder under the Inetpub\ wwwroot folder. Requests for files that reside below the virtual directory are handled by IIS.

IIS can implement some of the security required by the application (as discussed later) and can deliver requested HTML and media files to the client. IIS also maintains a list of filename extensions that are associated with particular server-side functionality. You can view these settings by starting the Internet Information Services management snap-in. In Control Panel, select Performance and Maintenance. In the pane that appears, select Administrative Tools and double-click on Internet Information Services. Open the entry for your computer (or the server on which you'll deploy your Web applications) and open the Web Sites folder. Right-click Default Web Site and choose Properties from the shortcut menu to display the Default Web Site Properties dialog box. Click on the Home Directory tab, and under Application Settings click the Configuration button.

The resulting Application Configuration dialog box is shown in Figure 16-1. Here you specify how files with different extensions are mapped to associated server-side functionality. The main functionality of ASP.NET Web applications is contained in ASP.NET pages, which have an .aspx filename extension. If you examine the line in the Application Mappings table for ASPX files, you'll see that these files are mapped to \Windows\Microsoft.NET\Framework\.NETVersion\aspnet_isapi.dll. This means that when a client requests an ASPX file, the request is delegated to the ASP.NET runtime (found in aspnet_isapi.dll), which executes the server-side functionality contained in such files.

Figure 16-1. The IIS Application Configuration dialog box, which shows the mapping of file types to server-side functionality

So far, so good. However, this is not really any different from the way an ASP application works. ASP.NET gets its additional power from hosting the .NET common language runtime. Consequently, any ASP.NET page has access to the features and functionality of the .NET Framework. For example

• In ASP, developers often use COM to access system functionality. In ASP.NET, developers have seamless access to all of the functionality in the .NET Framework class libraries.

• In ASP, server-side code can be developed only in a limited number of scripting languages. In ASP.NET, server-side code can be developed in any language that supports .NET. Different parts of an ASP.NET application can use different languages if required.

• The code in an ASP page is interpreted by scripting engines every time the page is accessed. Under ASP.NET, the page and its associated code are converted into one executable assembly. This assembly is cached and used each time the page is accessed, which speeds up the application execution by three to five times.

Fortunately, such benefits come without ASP developers having to sacrifice the model they're familiar with.

The Basic ASP.NET Programming Model

The basic ASP.NET programming model is essentially the same as that of ASP. The URL of the client request identifies a particular ASP.NET page, the functionality on the page is run, and any output generated is delivered back to the client. The format of an ASP.NET page will look familiar to an ASP developer. Consider the code shown in Welcome.aspx, which is provided as a sample file in the FourthCoffee solution.

Welcome.aspx

 <%@Pagelanguage="VJ#" %> <HTML> <% System.StringourName= "FourthCoffee"; System.StringoptimalBrowser= "IE"; System.StringthisBrowserName=get_Request().get_Browser().get_Browser(); %> <body> <Palign="center"><FONTsize="5"><STRONG>Welcometo<%=ourName%> </STRONG></FONT></P> <% if(thisBrowserName.Equals(optimalBrowser)) { %> <P><%get_Response().Write(ourName);%>arehappytowelcomeusers ofInternetExplorer.</P> <% } else { %> <P>ByemployingASP.NETWebcontrols, <%get_Response().Write(ourName);%>canalsoeasilywelcome usersof<%=thisBrowserName%>browsers.</P> <% } %> </body> </HTML> 

As you can see, you can embed code within the HTML contained in an ASP.NET page by using code render blocks that start with <% and end with %> . These blocks will be familiar to ASP developers, as will the ability to evaluate expressions using the syntax <%= expression %> . The code in Welcome.aspx uses code render blocks to wrap J# code around HTML statements. The if statement checks to see what browser the user is running and displays a message based on that browser, as shown in Figure 16-2.

Figure 16-2. You can embed J# code in an ASPX page to perform many tasks , including determining which browser a user is running.

The page shows several features of ASP.NET:

• The Page directive <%@ Page %> defines attributes relating to this ASP.NET page. The only attribute defined for this page is language , which indicates that the default language for code on this page is "VJ#" (note that it is not just "J#", which will not be recognized). This will also be reasonably familiar to ASP developers ”ASP directives are defined in a single delimiting block at the start of the page. We'll look at other directives and attributes later.

• Code render blocks are used to embed code within static HTML. The HTML sent back to the client will depend on the result of the if statement surrounding it. Variables can be declared in the code, and such variables obey the standard scoping rules for their language ”in this case J#. By default, a variable declared inside a code render block is scoped to the page (that is, it is visible in all code render blocks on that page only). If a variable is declared inside a code block delimited by parentheses ”{} ”then this variable is visible only to code inside these parentheses.

• Certain functionality is available automatically to the developer. As you'll see later, each ASP.NET page is actually an instance of a subclass of System.Web.UI.Page . This class exposes properties that represent abstractions of the underlying HTTP functionality. For example, the information sent by the client can be accessed through the Request property, which is an instance of System.Web.HttpRequest . In Welcome.aspx, this object is retrieved using the get_Request method. (Remember that an unqualified method is implicitly invoked on this .) The HttpRequest instance has a Browser property that is an instance of System.Web.HttpBrowserCapabilities . You can retrieve the name of the client browser from the HttpBrowserCapabilities instance by using the get_Browser property accessor method.

• You can generate dynamic output from code in several ways. One way is to use a code render evaluation block, delimited by <%= %> , to evaluate the J# code within the block. The result of this evaluation is placed in the output stream in place of the code render evaluation block. Alternatively, you can use the Write method of the current System.Web.HttpResponse instance to output any text. The current HttpResponse is available through the Response property of the current page. Both of these output mechanisms are used in Welcome.aspx.

Just to prove that there's nothing up our sleeves, you can see the result of running the page in another browser in Figure 16-3.

Figure 16-3. The server-side J# code can generate different output for different types of client Web browser.

One difference between ASP.NET and ASP is that in ASP.NET you can no longer define functions or subroutines in code render blocks. Instead, you must use method declarations enclosed in script tags:

 <scriptrunat="server"> System.Web.HttpBrowserCapabilitiesthisBrowser; System.StringthisBrowserName; privatevoidSetBrowserInfo(System.Web.HttpRequestreq) { thisBrowser=req.get_Browser(); thisBrowserName=thisBrowser.get_Browser(); } </script> 

It's important to remember the runat="server" attribute ” otherwise , the code will be interpreted as client-side script and you'll get errors when the page is processed . Also note that the script tag is not a direct replacement for code render blocks. You cannot use it to delimit inline code ”you can use it only to declare functions and variables. An example of the use of the <script> tag is provided in the Welcome2.aspx sample file.

By default, the language for code in a script element is assumed to be that defined in the <%@ Page %> directive. If you haven't defined a page-wide language, the application default will be used. Each Web application will have a default language defined in the compilation element of its Web.config file:

 <configuration> <system.web> <compilation defaultLanguage="VJ#"  debug="true" /> </system.web> </configuration> 

This default definition is overridden by a page-level language declaration. All code in code render blocks must be written in the language defined either by the language attribute of the <%@ Page %> directive or the Web.config compilation element. We'll look at the syntax and content of the Web.config file in more detail later. The sample file Welcome3.aspx uses the <%@Page %> directive to override the default language defined in Web.config (J#) and use Visual Basic .NET instead.

If you haven't set the language for the page, you can override the application-level default language using the language attribute of the script element:

 <scriptrunat="server" language="C#"> </script> 

Be careful with this feature: You can use only one language per page, so if you declare the language in multiple places, the declarations must match. If you try running the sample file Welcome4.aspx, which contains a mixture of J# and Visual Basic .NET code, you'll get a compilation error.

You might wonder why the default language is defined in an element called compilation . There's a good reason for this. As mentioned earlier, when an ASPX page is first accessed, the text and code are converted into a new class that will contain any code defined in the ASPX page along with code commands to output the static HTML content at the appropriate place. This new class is then compiled into MSIL and executed. The precise mechanism is described later in the chapter.

To do any real work in your Web application, you must access the .NET Framework or classes that you've written yourself or obtained from third parties. To use a class in your page, you can specify its fully qualified name:

 <%System.Xml.XmlDocumentdoc=newSystem.Xml.XmlDocument();%> 

However, this can soon become tiresome, so you can import the whole namespace (as you can in J#) by using the <%@ Import %> directive:

 <%@Importnamespace="System.Xml" %> <%XmlDocumentdoc=newXmlDocument();%> 

You can see this example of importing a namespace in the sample file Welcome2.aspx. By default, the following namespaces are imported into an ASP.NET page:

• System

• System.Collections

• System.Collections.Specialized

• System.Configuration

• System.IO

• System.Text

• System.Text.RegularExpressions

• System.Web

• System.Web.Caching

• System.Web.Security

• System.Web.SessionState

• System.Web.UI

• System.Web.UI.HtmlControls

• System.Web.UI.WebControls

You must ensure that the assemblies containing the classes you're importing are available to the page both at compile time and run time. If you place the assemblies in the bin directory under the Web application's virtual directory, they'll be automatically linked to the application. You must link any other assemblies explicitly by using the <%@ Assembly %> directive to link the assembly to the current page.

I l @ ve RuBoard