BA 372 - ASP.Net Lab

This lab contains exercises that familiarize you with ASP.Net and its deployment and development with Visual Studio 2005. ASP.Net or Active Service Pages is a Microsoft technology for developing and deploying dynamic Web sites; i.e., Web sites of which the contents is dynamically determined when requested by a user or program.

In this lab, we'll only work with ASP.Net. In the older, non.Net versions of ASP, ASP code segments would be embedded in HTML pages. When the page was requested from the server, Microsoft's IIS web server parsed the HTML and ASP. Whereas the HTML was routed straight through, the ASP parts of the code got interpreted and executed. Its results, HTML, text, XML, etc., were then routed back to the requester. This method is very similar in nature to other embedded-HTML languages such as PHP (we'll get exposure to PHP in our LAMP lab).

However, in the newer, .Net implementations of ASP, ASP is used as a technology to fuse nonweb code; e.g., functions and class libraries written in .Net languages with Web contents without the programmers having to worry a great deal about how that fusion actually takes place.

A word of warning. The concepts and materials you'll encounter in this lab are quite 'involved,' meaning that there's a whole world of technology and programming concepts behind them. Many of these concepts we have seen and explored; e.g., VB.Net, HTTP, HTML, OOP, etc. However, in this ASP.Net world, they really all get fused into a cohesive whole. When you work this lab, work it carefully and slowly!! Make sure that in your mind it's clear how things work. Do not!! just go through the movements of cutting and pasting code. Successful completion of Assignment 3 hinges on proper understanding of this lab.

VS 2005 built-in Web server:

One of the issues that makes web-based programming a bit trickier than nonweb-based programming is that in order to run a web-based program, you need a web server through which to request the program. In many cases, your company web server will not be available for this type of development runs--after all, we do not want the production and development side of the house to be intermixed--so traditionally you'd have to install a web server on your development machine or copy files over to a shared web server to do web development. Especially in lab situations such as ours, this can be a real hassle and hence, we were all very happy when it was announced that each copy of VS2005 has its own, built-in Web server that is used to run .Net web-based programs during development. The server is automatically started when running or debugging an ASP.Net page.

hello.aspx

In VS 2005, start a new ASP.Net web-site (File-->New Web Site --> ASP.Net Website) .

Double-click on the Default.aspx component of the Web site and notice how the blank Web page in the editor is set to Design mode.

Click on the Source tab on the bottom of the page.

Replace the default code with the following:

Build and run the code.

Notice how the Web page is displayed in your browser (VS 2005 invokes your browser and your browser makes the HTTP request for the Web page).

Notice in the URL line of your browser how the page is requested from the built-in Web server: http://localhost:...

Look at the page source (View-->Page Source) of the page and notice how the <body> has been filled with the Hello, world... string.

Now look at the code:

Notice how in the code the HTML <body> contains only a single line:

<asp:Literal
id="HelloWorld" runat="server" />

This code tells the IIS server (remember, this is a Microsoft technology and you cannot serve an ASP page like this from a nonMicrosoft server such as Apache), that at this location a literal string (Literal) called HelloWorld must be put.

Now, as the compiler builds (compiles) this Web page, it runs into the <Script>...</Script> section.

At the top of the page is a so-called directive (<%@ Page Language="VB" %>) that tells the compiler and IIS that the default language for code on this page is VB.

Hence, it checks and parses the code inside the <Script>...</Script> tags accordingly.

Inside, it finds the VB.Net code for the subroutine Page_Load(). Notice how it is normal VB code except for one thing:

The VB code refers to an object called HelloWorld and sets its Text attribute.

HelloWorld.Text
= "Hello, world..."

However, this HelloWorld object is not declared anywhere in the script. Instead it refers to the asp:Literal declared in the <body> section of the page:

<asp:Literal
id="HelloWorld" runat="server" />

The Page_Load() subroutine is automatically called when the page gets loaded by the server. Hence, as the Web page runs on the IIS server, the asp:Literal HelloWorld's Text attribute is set to Hello, world... which in its turn replaces the <asp:Literal> of the HTML <body> tag.

So, in the page source of the HTML page displayed on your browser, you only see the Hello, world... text.

Make sure you thoroughly understand this mechanism as it is the basis of all of this lab.

Some modifications: ten instead of one Hello, world's:

<%@ Page Language="VB" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<Script runat="server">
     Sub Page_Load(ByVal Sender As Object, ByVal E As EventArgs)
         Dim myString As String = "<li> Hello, world...</li>"
         Dim i As Short

         For i = 0 To 8 Step 1
             myString = myString + "<li>Hello, world...</li>"
         Next
         HelloWorld.Text = myString
     End Sub
</Script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title>Example</title></head>
<body>
<ol>
<asp:Literal id="HelloWorld" runat="server" />
</ol>
</body>
</html>

Notice a few things:

The Page_Load() function has been modified to create a single longer string, that consists of ten <li> Hello, world...</li> strings concatenated together into one.

This string is then used to set HelloWorld.Text.

The HTML list elements get numbered 1-10 because the asp:Literal HelloWorld sits between the <ol> and </ol> (ordered list) HTML tags.

We can include any VB code in our <Script> that we want.

Similarly, we can set multiple literals; same behavior, different approach:

<%@ Page Language="VB" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<Script runat="server">
     Sub Page_Load(ByVal Sender As Object, ByVal E As EventArgs)
         Dim myString As String = "<li> Hello, world...</li>"

         HelloWorld1.Text = myString
         HelloWorld2.Text = myString
         HelloWorld3.Text = myString
         HelloWorld4.Text = myString
         HelloWorld5.Text = myString
      End Sub
</Script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title>Example</title></head>
<body>
<ol>
<asp:Literal id="HelloWorld1" runat="server" />
<asp:Literal id="HelloWorld2" runat="server" />
<asp:Literal id="HelloWorld3" runat="server" />
<asp:Literal id="HelloWorld4" runat="server" />
<asp:Literal id="HelloWorld5" runat="server" />
</ol>
</body>
</html>

Clearly, with this little mechanism alone, we could generate a great variety of Web pages. For instance, our Page_Load() sub could go out to a database, do some retrievals and post the results to our HTML Web page.

Another example; let's see if we can take a peek at the file system of the server (remember, the 'server' is the built-in one that runs on your local machine)?!

<%@ Page Language="VB" %>
<%@ Import Namespace="System" %>
<%@ Import Namespace="System.IO" %>

<Script runat="server">
     Sub Page_Load(ByVal Sender As Object, ByVal E As EventArgs)

         Dim files As String() = System.IO.Directory.GetFiles("C:", "*")

         Dim myFiles As String = ""
         Dim myFile As String
         For Each myFile In files
             myFiles = myFiles + myFile + "<BR/>"
         Next
         theFiles.Text = myFiles
     End Sub
</Script>

<html xmlns="http://www.w3.org/1999/xhtml" >
<head><title>Example</title></head>
<body>
<asp:Literal ID="theFiles" runat="server" />
</body>
</html>

Note the following:

We are getting all the files (*) from the C: drive. (you might want to change the drive:\directory combination).

We can use a For Each construct to loop through an array.

We, once again, build up one long string (myFiles), which we then assign to the asp:Literal's Text attribute.

Have you, here and in the previous codes, noticed the runat="server" attributes of both the <Script> and the <asp:Literal>? These indicate to the compiler that those code segments must run on the server.

So far, we have included VB.Net code within a separate <Script> section on the aspx page. However, we may instead want to separate the code in the <Script> from the aspx page. ASP's so-called code-behind facility allows us to do just that:

Replace the code by the following:

<%@ Page Language="VB" AutoEventWireup="false" CodeFile="Default.aspx.vb" Inherits="MyPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
    <title>Untitled Page</title>
</head>
<body>
    <form id="form1" runat="server">
    <div>
        <asp:Literal ID="MyLiteral" runat="server"></asp:Literal></div>
    </form>
</body>
</html>

Notice that the page no longer contains a <Script>.

Now, double click on the Default.aspx.vb file to bring it into the code editor and replace its default code with the following:

Partial
Class MyPage

    Inherits System.Web.UI.Page

Protected Sub Page_Load(ByVal sender As Object, ByVal e As System.EventArgs)
   'Trace.IsEnabled = True
    MyLiteral.Text = "Hello, world..."
   'Trace.Write("After setting Output")
End Sub
End Class

Notice how, in concept, this code is equivalent to what we previously did using the <Script>. Again, the Literal's Text attribute gets set. However, in this case the code is separated out in a 'pure' VB.Net subroutine that will get compiled into the aspx application.

Also note how in the top line of the aspx file the connection with the VB language and the aspx.vb file is declared.

Build and run the app.

One of the things that makes Web programming a bit harder than nonWeb programming is the complexity of debugging a Web-based program. Whereas in a nonWeb environment we can simply run our executable code through a debugger (we have done so several times in VB.Net so far), with an HTTP client and server layers added into the mix, debugging a Web app often requires some juggling and skillful OS-level programming.

Fortunately, the combination of ASP.Net, VS 2005 and its built-in Web server gives us pretty much exactly what we need. For instance:

In your Default.aspx.vb file, set a breakpoint on the End Sub statement and start debugging. Notice how the application halts at the breakpoint and how you can inspect, in the usual manner, the contents of the Output literal.

Uncomment the first Trace... line (Trace.IsEnabled = True) in the code; build and run.

Notice how your browser now lists a complete set of information on your running aspx app. Among other things it shows:

Pretty much all HTTP information involved in the exchange between your browser and your built-in Web server (e.g., request headers, response header, server variables, etc.). Study these variables, some of them should look very familiar by now.

Uncomment the Trace.Write("After setting Output") line and build and run the program.

Notice how in the Trace Information section of your browser's output, the Trace.Write()information appears. Notice that it was the first trace command executed (it's in the Page_Load() subroutine so it's the first thing executed on this page. Notice, also how many other subs are executed after Page_Load() (e.g., LoadComplete, Prerender, Render, etc.). This whole stack indicates all the default routines called when rendering an aspx Web page. Programmers can provide code for each and any of these if so desired.

Maintaining state:

The asp:Literal is a very nice 'all-purpose bag.' Since it's just a string, you can dump any length and complexity of HTML code into it. For instance, your code-behind program could go out to a database, make queries and return the query results as a Literal to the browser.

However, as discussed in our HTTP class, any sort of interactive engagement with an HTTP server; e.g., e-commerce applications, requires that we maintain state between different invocations of the server. As discussed in class, however, HTTP is stateless and hence, does not support state maintenance across subsequent requests.

We discussed several ways to bypass HTTP statelessness. One of them was by passing state information to-and-from the browser by 'burying' it into the <input type="hidden> tags inside an HTML <form> (we called it 'memory-on-the-go').

For instance, let's have the server prompt us for our name using an HTML <form> and once we fill out the form and pass its parameters back to the server, it will read the data passed and echo them back to us as a welcome/greeting.

To the Web site, add a new Web form (right click the app -->Add new Item-->Web form).

Switch your focus to the new Web form.

While in Design mode, drag a TextBox, Label and a Button from the Toolbox onto the Web page.

Display the source of the form in the editor and notice how an <asp:TextBox> and <asp:Button> have been placed inside the <asp:form>.

Change the button's Text attribute to Register.

Change its (ID) to RegisterButton.

Change the label's Text attribute to Name?

Change its (ID) to PromptLabel.

In Design view, double-click the button and notice how, as in standard VB.Net, an event handler for it is created in the associated .vb file.

Add a Literal to the form; this is the literal we'll use to thank the user for registering.

Change the Literal's (ID) to WelcomeLiteral.

Lay the componnets out from left to right in the order: Label--> Textbox --> Button --> Literal

Replace the skeleton code for RegisterButton_Click() with the following:

Protected Sub RegisterButton_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles RegisterButton.Click
    'Trace.IsEnabled=True
     RegisterButton.Visible = False
     RegisterTextBox.Visible = False
     PromptLabel.Visible = False
     WelcomeLiteral.Text = "Thank you for registering " + RegisterTextBox.Text
End Sub

Build and run this code; type a string in the form's input box and notice how on clicking the button, the string gets returned to the Web browser.

Now let's see what actually transpired here (we have already seen this as part of our HTTP discussions).

Run the app again, but this time do not enter your name in the text box. Instead, look at the page source of the form: Notice that the <form> contains the following HTML <input> field:

Notice that the button is represented as another input field with type submit, indicating that clicking it will trigger the form's input fields to be passed to the server.

Notice that the form is declared as:

When the form is submitted back to the server it will trigger the code stored in Default2.aspx (the code we just wrote).

Also notice that the form's HTTP request method is declared as post, indicating that any data that must be passed from the HTTP request to the HTTP server, will be passed in the body of the HTTP request.

So what happens when you push the RegisterButton?

The value of input field RegisterTextBox will hold the text you filled out in the text box.

This field is passed as the RegisterTextBox parameter to Default2.aspx on the server.

Default2.aspx running on the server will pull your string information out of RegisterTextBox and then generates an HTML page with that text on it through its asp:Literal, and then send that text back to the browser.

To actually see this work, uncomment the Trace.IsEnabled=True line, build and run the program and watch the variables in the Form Collection section of the trace report.

Finally, let's build a small application that really must 'accumulate' some memory over consecutive client-server interactions. We'll have a text box in which we enter a string and every time we come back, the new string is concatenated to the previous string.

Change the Text of the RegisterButton into Append...

Change the (ID) of the WelcomeLiteral into AppendLiteral.

Change the (ID) of the RegisterTextbox into AppendTextBox.

Delete the Label.

Replace the VB.Net code with the following:

Partial Class Default2
    Inherits System.Web.UI.Page

    Private myString As String = ""

    Protected Sub RegisterButton_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles RegisterButton.Click
        AppendLiteral.Text = ViewState("myString") + " " + AppendTextBox.Text
        ViewState.Add("myString", ViewState("myString") + " " + AppendTextBox.Text)
    End Sub
End Class

Build and run the program. Keep entering strings in the textbox and hit the 'Append' button. Notice how on the reply it accumulates in a single string all the previous strings plus the current string.

Again, how does this work?

We define a Default2 class member myString as String and initialize it to the empty string ("").

Coming in to the RegisterButton_Click() event handler, we call ViewState("myString").

With a call to ViewState() we can retrieve state information that was previously stored there. This state information is stored in the HTML <input id="__VIEWSTATE"> field in the HTML file that the server sends out. (study the page source of the HTML page!).

Notice how this __ViewState data is encoded/encrypted in the form passed to us from the server and how we cannot read its contents. However, once this <input> field gets passed back to the server, the server can decode it and we, on the server side, can access that state information with a call to ViewState().

With the call ViewState.Add() we can put a new state into the myString variable. Hence, with every call to RegisterButton_Click() we first pull out the last value stored in ViewState, append the newly entered string to it and stick the result into AppendLiteral.Text, after which we append the newly entered string to myString and stick it back into ViewState.

Notice how all ViewState information is passed back to the browser as hidden input, after which when the browser makes its next request, it gets passed back to the server as a variable. Since the input field has a type="hidden" the browser won't show it when rendering the page.

As discussed during our HTTP class, moving state information (memory) back and forth between client and server works fine as long as the amount of information in ViewState does not get too large. Once it gets large we must start thinking of better methods to keep track of state information; e.g., storing it on the server or client side.

Replace the calls to ViewState() and ViewState.Add() with calls to Session() and Session.Add().

The code seems to run the same, but in this case, the information myString is kept in a cookie rather than through an hidden HTML <input> field.