Professional ASP.NET 1.1 [Electronic resources] نسخه متنی

ASP.NET

There are many changes to take into account when looking purely at ASP pages. The most obvious are the server controls and the postback architecture. These have been covered extensively in earlier chapters of the book, so now we'll move on to other features that still exist in ASP.NET, but are different from ASP. We'll also abbreviate explanations of changes that are explained in detail elsewhere in this book, and instead provide a summary and reference to them. Since ASP.NET is fully class-based, we'll also provide references to the underlying classes, so you can easily find full information in the documentation, or look up the classes in tools such as WinCV and ILDasm.

Preparing the Way

Before we delve into the changes in detail, here's a quick list of things you can do now, in your current ASP pages, to pave the way for migrating to ASP.NET:

• 
  

  Use only a single language within each ASP page



• 
  

  Use Option Explicit to enforce declaration of variables



• 
  

  Use <script> blocks for function declaration instead of <% %> blocks



• 
  

  Avoid render functions



• 
  

  Use the Call keyword for calling functions, to force the use of parentheses around arguments



• 
  

  Avoid default properties, such as Recordset("column") instead of Recordset.Fields("column").Value
  



• 
  

  Explicitly close open resources (such as the file system or recordsets)

  
  
  
  
  

  Note

  These are only relevant to server-side code – client-side code is still browser related.

  
  

Many of these are best practices anyway, but we all tend to take shortcuts. Adhering to this list will ease your migration path. You'll be looking at these in detail as you go through the chapter.

Intrinsic Objects

Most ASP intrinsic objects remain available and unchanged, providing excellent support for existing applications. However, there are changes to some properties and methods, as well as the addition of new ones. One significant change is the removal of the ASPError object, as error handling is now managed by exceptions.

The Application Object

ASP.NET application state handling is implemented by the HttpApplicationState class in the System.Web namespace. Although ASP.NET supports ASP functionality by way of the Contents and StaticObjects collections, there are some minor differences that may confuse you if you check the documentation. The reason is HttpApplicationState is a first class object that implements a collection (used to hold the items in application state). Therefore methods such as Remove and RemoveAll are members of the HttpApplicationState object itself. However, to preserve compatibility, there is also a Contents property, which simply points back to the parent object. Thus, the following lines of code are equivalent.

In VB.NET, the code is:

Application.Remove("Item1")
Application.Contents.Remove("Item1")

The code in C# is:

Application.Remove("Item1");
Application.Contents.Remove("Item1");

The first line in these code examples is what you'd see in .NET code samples, whereas the second line is how you'd do it in ASP. However, because compatibility has been preserved, they both work.

New features of the application object are shown in the following table. Note that although there are explicit Add and Get methods, the existing way of accessing the collection still works fine:

Objects in Application State

In ASP it was always taboo to store single-threaded objects in application state, which was a real problem for Visual Basic programmers developing components. Given that the .NET languages (including Visual Basic) allow the production of free-threaded components, has this problem now gone away? Well, to a degree yes, as long as you understand the following:

• 
  

  You can store free-threaded components as long as they provide thread synchronization.



• 
  

  You can store single-threaded components if you use Lock and Unlock to protect against thread blocks.



• 
  

  Application state has no guaranteed durability. The application domain can be torn down at any time (synchronized restart for example), so for durability you need an external store.

By and large, the storage of objects in Application state is discouraged because of the resources used, and the potential for scalability and performance problems. However, the storage of scalar type data (such as string) is a great way to get some performance improvement, as long as it is used carefully. You might think that the classic case of wanting to store Recordsets in application state is now easy, since you can store the XML from a DataSet, but remember that memory (although cheap) is finite. Frequent use of a 10Mb set of data stored in application state may give great benefits, but 100Mb may not. This sort of scenario needs full testing before the implications are really known.

The Session Object

Session state is implemented by the HttpSessionState class in the System.Web.SessionState namespace. The Contents and StaticObjects follow the same rules as Application state – the structure of the class is different from ASP, but access works in the same way. Thus, the following examples are equivalent. In VB.NET:

Session.Remove("Item1")
Session.Contents.Remove("Item"1)

In C#:

Session.Remove("Item1");
Session.Contents.Remove("Item1");

The changed and new features of the session object are shown in the following table:

The Request Object

The request is implemented by the HttpRequest class in the System.Web namespace. All of the existing properties and methods are supported, although there are some notable exceptions regarding the use of collections (see in the following table) where the appropriate ASP 3.0 ServerVariables equivalent has been mentioned. New and changed properties or methods are detailed in corresponding fonts as follows:

Some of this information is still available through the ServerVariables collection, but has now been abstracted out into more accessible properties.

The Request object supports collections for accessing the contents of a form or query string, and there are some major implications where those contents contain elements of the same name. This is typically the case where check boxes, radio buttons, or multi-select list boxes are used. For example, consider the following ASP form:

<form action="foo.asp" method="post">
Select your favorite editor:
<select name="editor" multiple="multiple">
<option>Notepad
<option>Textpad
<option>Visual Studio .NET
</select>
<p/>
<input type="submit" value="Send">
</form>

To extract the selected values from the multi-select list you could use:

For item = 1 To Request.Form("editor").Count
Response.Write Request.Form("editor")(item) & "<br/>"
Next

However, this code will not work in ASP.NET, as a NameValueCollection represents the form contents. There are two points about this:

• 
  

  The collection is zero based



• 
  

  You have to explicitly get the values

For example:

Dim item As Integer
For item = 0 To Request.Form.GetValues("editor").Length - 1
Response.Write (Request.Form.GetValues("editor")(item) & "<br/>")
Next

Here you have to use the GetValues() method of the collection, and index into that (using a base of 0) to get the required value.

The Response Object

The response to a request is implemented by the HttpResponse class. Like the request, all existing functionality is kept, with the following changes or additions:

The Server Object

The Server object is implemented by the HttpServerUtility class in the System.Web namespace. The additions and changes are detailed as follows:

The ASPError Object

The ASPError object has been removed, as errors are now represented by exceptions. For example, the following code extracts the last error:

Dim lastError As Exception
lastError = Server.GetLastError()
Response.Write("Error was: " & lastError.Message)

The ObjectContext Object

The ObjectContext object in ASP is designed for the integration of ASP pages with external transacted components, such as those in Microsoft Transaction Server (MTS) or COM+ Services. Within ASP.NET you have the ability to run pages with ASP Page Compatibility, by setting a page directive:

<%@ Page AspCompat="true" %>

This allows the page to be run on a single threaded apartment (STA) thread, allowing it to call STA components, such as those written in VB6. This is particularly useful for those components that reference the ASP intrinsic objects and generate HTML.

The Page Object

The Page object (in the System.Web.UI namespace) was not a part of ASP, but plays an important role in ASP.NET. The Page is the parent object for the objects mentioned above, apart from the ObjectContext. Many of the features of the page you'll already have seen (such as the IsPostBack and IsValid properties), and the rest are extensively documented in the help files. We mention this object here in case you see code such as Page.Session, Page.Response, or Page.Request, and wonder how the objects relate.

Page Changes

Along with changes to the common objects, the structure and usage of ASP pages have changed. You've already seen how the event model and postback architecture changes the layout of pages, so what you'll concentrate on here are the things that need changing from existing ASP pages.

Single Language Per Page

I've never actually seen any code that used more than one server-side language, but with ASP.NET you must use a single language per page. If you need to use multiple languages you'll have to use User Controls or custom controls, which can be in any language.

Script Blocks

Procedures in ASP.NET pages have to reside within proper script tags. So, the following is no longer allowed:

<%
Sub Foo()
...
End Sub
%>

Instead you must use:

<script language="VB" runat="server">
Sub Foo()
...
End Sub
</script>

You can still use the <% %> tags for inline placement of variables or function results.

Code Render Functions

The changes to script block usage mean that render functions are no longer allowed. Render functions are where the body of a function actually contains HTML. For example:

<% Sub ShowSeparator() %>
<img src="sep.gif" width="100%"></img>
<% End Sub %>

This now has to be:

<script language="VB" runat="server">
Sub ShowSeparator()
Response.Write("<img src='sep.gif' width='100%'></img>")
End Sub
</script>