Top-to-Bottom vs. Event-Driven Programming

Classic ASP pages using render blocks always executed from top to bottom, with code in < % % > render blocks being executed and output to the response stream as it was encountered by the ASP interpreter.

ASP.NET code is compiled into an instance of the Page class, and execution is event-based . Rather than placing start-up code in the first render block in a page, start-up code in ASP.NET is placed in the Page_Load event handler, which is fired when the instance of the Page class that represents the page is loaded into memory. Likewise, a Page_Unload event is fired just before the page is removed from memory and can be used to run any necessary clean-up code.

Page Directives

In classic ASP, the primary directive used in pages was the @ Language directive, which specified the language to be used for render blocks. Other less commonly used directives included @ Codepage , @ EnableSessionState , @ LCID , and @ Transaction .

In ASP.NET, these directives are attributes of the @ Page directive, which should appear at the top of each ASP.NET Web Form page. See Chapter 7 for a full discussion of the @ Page directive and its attributes.

One new attribute of the @ Page directive that is important to discuss in this context is the AspCompat attribute. By default, ASP.NET runs as a multi- threaded apartment (MTA) process. This means that components that run as single-threaded apartment (STA) components, such as those written in Visual Basic 6.0, are not compatible with ASP.NET. This includes the ADO components, which are installed to run as STA components by default. (You can modify the threading model for ADO by running a batch file that changes the registry settings for ADO, but that is beyond the scope of this discussion.) Setting the AspCompat attribute to true forces ASP.NET to run in STA mode, making it possible to use STA components in ASP.NET pages.

Language Changes

In addition to changes in the structure of pages in ASP.NET, some significant changes to the Visual Basic language will likely require modifications to your code. These include the following:

• Set and Let are no longer needed or supported. Object references can be set by simple assignment:

  Object1 = Object2
  

• Parentheses are now required for calling Sub procedures as well as Function procedures (including methods that do not have parameters):

  Response.Write("Hello, World!")
  

• The Variant data type does not exist in Visual Basic .NET. The replacement is Object .

• Default properties are not supported, unless they take arguments, so it’s best to call all properties explicitly:

  MyString = TextBox1.Text
  

• Property declaration syntax has changed. Instead of Property Set , Property Get , and Property Let , Visual Basic .NET uses the following syntax. (You can use any name you want as the argument to Set , but if you don’t supply one, Value is used automatically.)

  Public Property MyProperty() As String Get Return MyInternalVariable End Get Set (ByVal Value as String) MyInternalVariable = Value End Set End Property
  

• The default for passing parameters to procedures has changed from ByRef to ByVal . To pass values by reference, you must explicitly add the ByRef keyword. (Reference parameters allow you to change their values in the procedure to which they’re passed and retrieve their values outside the procedure.)

  Sub MySub(ByRef MyValue As String) MyValue = "Hello!" End Sub
  

Migrating a Data Access Page to ASP.NET

To demonstrate some of these changes and how you should deal with them, let’s walk through the process of migrating a classic ASP page that accesses data in a Microsoft SQL Server database through ADO and writes it to the page as an HTML table. First you’ll go through the process of making the page work in ASP.NET, while still using ADO for data access and using the same logic for writing the data as an HTML table. Then you’ll modify that code to access the data through ADO.NET and use an ASP.NET DataGrid to automatically render the data as a table. The following listing shows the classic ASP page that you’ll start with.

GetAuthors.asp

<%@ Language=VBScript %> <html> <head> <% Dim objConn Dim objCmd Dim objRS Dim strConn ' Do NOT use the sa account in data access code, as shown in ' the connection string below! Doing so is a MAJOR security risk! ' Change the connection string to either use a trusted connection, ' Or to use a less-privileged account to access the database. strConn = "PROVIDER=SQLOLEDB;INITIAL CATALOG=PUBS; "_ &"SERVER=(local)\VSdotNet;uid=sa;pwd=;" Set objConn = Server.CreateObject("ADODB.Connection") Set objCmd = Server.CreateObject("ADODB.Command") Set objRS = Server.CreateObject("ADODB.Recordset") objCmd.CommandText = "SELECT * FROM Authors" objConn.Open strConn Set objCmd.ActiveConnection = objConn Set objRS = objCmd.Execute Sub FormatTable Dim objField If Not objRS.EOF Then Response.Write "<table border=2 cellspacing=0>" Do While Not objRS.EOF Response.Write "<tr>" For Each objField In objRS.Fields Response.Write "<td>" & objField & "</td>" Next Response.Write "</tr>" objRS.MoveNext Loop Response.Write "</table>" Else Response.Write "No Records!" End If End Sub Sub CleanUp() objConn.Close Set objConn = Nothing Set objCmd = Nothing Set objRS = Nothing End Sub %> </head> <body> <% FormatTable() CleanUp() %> </body> </html>

The following illustration shows the output of this page.

The page in the previous listing accesses the Authors table of the Pubs SQL Server sample database (in this case in the VSdotNET MSDE instance installed with Visual Studio .NET). The page then calls a render function to write the data to the page as an HTML table, and then calls a clean-up function, which closes the connection to the database and sets the object references to Nothing to ensure that the COM subsystem knows these objects can be destroyed . (See Appendix C for details on setting up MSDE.)

Short-Term Migration

In the short term, your goal might be to simply move your pages over to ASP.NET while still using most of the existing logic in the page. Though this choice has performance implications, it can make your migration easier by letting you do it in stages. Making the code in the previous listing work as an ASP.NET page is largely a matter of modifying it to comply with the rules for ASP.NET code.

The first thing you should do is save a copy of the page to be migrated with the .aspx extension and try to run it. Although it’s unlikely that pages of any complexity will run unaltered, you might be surprised at what will run. More important, when you attempt to run the page and it fails, ASP.NET will give you information about why it failed and which line caused the failure. (Remember from Chapter 14 that to get the most error information, you should set your pages to compile in debug mode. You can do this either by setting the debug attribute of the @ Page directive or by turning on debug mode in Web.config.) The following illustration shows the page that results from attempting to run GetAuthors.asp as an ASP.NET page.

As you can see in the preceding illustration, you get immediate feedback that the Set statements need to be removed from your code. Thanks to the improvement in error information in ASP.NET, you can simply change a page’s extension to .aspx, attempt to run it, correct the error that is flagged, attempt to run it again, correct the next error to be flagged, and so on, until the page runs without errors.

The following example will take a more structured approach and correct all of the structural and language incompatibilities before attempting to rerun the code.

If you haven’t already done so, save the code in the GetAuthors.asp listing. (Change the user ID and password to one that is set up on your machine or use a trusted connection, if desired.) Once you have that running, save a copy as GetAuthors.aspx.

Make an ASP page work in ASP.NET

1. Starting from the top of the page, modify the @ Language directive to @ Page to use Visual Basic as the language, and add the AspCompat attribute so that you can use the ADO components in STA mode:

   <%@ Page Language="VB" AspCompat="True" %>
   

2. Although the code that creates and instantiates the ADO objects will run in a render block without modification in ASP.NET, the FormatTable and CleanUp procedures will not. You need to move them into a < script > block. Since leaving the ADO code in a render block will not allow you to control when it executes, move it into a < script > block as well and run it in the Page_Load event handler. Move the clean-up code to the Page_Unload handler. (You no longer need the Set obj = Nothing statements because ASP.NET takes care of this clean-up for you.) Note that you must also remove the Set statements from the code and add parentheses to the objConn.Open and objConn.Close calls.

   <head> <script runat="server"> Dim objConn Dim objCmd Dim objRS Sub Page_Load() Dim strConn ' Do NOT use the sa account in data access code, as shown in ' the connection string below! Doing so is a MAJOR security risk! ' Change the connection string to either use a trusted connection, ' or to use a less-privileged account to access the database. strConn = "PROVIDER=SQLOLEDB;INITIAL CATALOG=PUBS;" _ & "SERVER=(local)\VSdotNET;uid=sa;pwd=;" objConn = Server.CreateObject("ADODB.Connection") objCmd = Server.CreateObject("ADODB.Command") objRS = Server.CreateObject("ADODB.Recordset") objCmd.CommandText = "SELECT * FROM Authors" objConn.Open(strConn) objCmd.ActiveConnection = objConn objRS = objCmd.Execute End Sub Sub FormatTable Dim objField If Not objRS.EOF Then Response.Write("<table border=2 cellspacing=0>") Do While Not objRS.EOF Response.Write("<tr>") For Each objField In objRS.Fields Response.Write("<td>" & objField.Value & _ "</td>") Next Response.Write("</tr>") objRS.MoveNext Loop Response.Write("</table>") Else Response.Write("No Records! ") End If End Sub Sub Page_Unload() objConn.Close() End Sub </script> </head>
   

3. Remove the call to CleanUp from the render block in the body of the page.

4. Save the page and browse it. The output should be the same as in the illustration on page 506.

Long-Term Migration

Techniques such as using AspCompat to allow use of STA components in ASP.NET can help you get pages up and running in ASP.NET more quickly. But in the long run, it’s best to fully migrate your code to take advantage of the features offered by ASP.NET and ADO.NET. The listing below shows the changes necessary to get the functional equivalent of GetAuthors.asp using ADO.NET, and to use an ASP.NET DataGrid to display the data rather than writing your own rendering code.

GetAuthors2.aspx

<%@ Page Language="VB" %> <%@ Import Namespace="System.Data" %> <%@ Import Namespace="System.Data.SqlClient" %> <html> <head> <script runat="server"> Sub Page_Load() Dim myDS As New DataSet() Dim ConnStr As String ConnStr = "server=(local)\VSdotNET;database=pubs;" ConnStr &= "Trusted_Connection=yes" Dim SQLSelect As String SQLSelect = "SELECT * FROM Authors" Dim mySqlConn As New SqlConnection(ConnStr) Dim mySqlDA As New SqlDataAdapter(SQLSelect, ConnStr) mySqlDA.Fill(myDS) MyGrid.DataSource = myDS.Tables(0).DefaultView DataBind() End Sub </script> </head> <body> <form runat="server"> <asp:label id="title" text="ASP to ASP.NET Migration: Step 2" font-

size

="18" runat="server"/> <asp:datagrid id="MyGrid" autogeneratecolumns="true" border="2"

cellpadding

="0" runat="server"/> </form> </body> </html>

When you save and run the code in the GetAuthors.aspx listing, you should see results in output similar to the following illustration.

The code in the preceding listing offers better performance because it does not rely on AspCompat to run. It takes advantage of ADO.NET instead of using ADO through COM Interop (which carries some performance overhead). The code could be made even more efficient by using an ADO.NET DataReader to access the data. The code in the preceding listing also provides greater flexibility for modifying the look of the rendered table. Now you can modify the output format by adding attributes to the DataGrid tag (or using predefined styles). Using an ASP.NET DataGrid also provides built-in support for paging, editing, and filtering. See Chapter 9 for more information on these features.