Resources | ASP | ASP -> .NET

Convert ASP to .NET:

With its introduction of .NET, Microsoft has made claims of enormous benefits to be gained by converting to their new platform. In my experience, converting your ASP code to the .NET platform will have a significant impact on the performance of a typical ASP page (while doing stress tests on a recently converted web server, I noticed about an 18-20% performance gain). One area where I did have some trouble was converting ASP pages that were reliant on COM+ objects. In those cases, performance sometimes actually suffered (though not by much) -- a problem that was resolved by making some changes to the way "state" was being maintained.

If you are planning on making the switch to .NET, you are probably interested in finding out what changes you are going to have to make to your code. The good news is that its not that difficult (though it can be somewhat tedious) to make the neccessary changes in your ASP code, and you have a couple of options. The following tutorial is intended to give you a brief overview of what to expect if you make the switch to .NET for your web site.

As I said, you have some options when converting your site to this new platform. The first thing to keep in mind is that the .NET platform is backwards compatible with ASP 3.0. So one way to handle the upgrade is to keep all of your old .ASP files unchanged and just code your new pages with ASP.NET (old ASP files will have the .asp file extension, while ASP.NET files will have the .aspx file extension). Your old pages won't see any performance benefits from transferring to .NET, but it is the quickest way to make the transition.

In order to get the full benefit of upgrading to .NET, however, you are going to have to update your old .ASP files. Here are some guidelines to keep in mind while doing this.

Sections:  Asp Delimiters | Request Object | VBScript | Transactions | Threading

Asp Delimiters -- <% %>

In the old ASP, when you were writing code for your functions you would just put it inside the <% and %> tags. In ASP.NET, that is not allowed. Instead, you must put your code within script blocks, and then make the call to the function within the ASP delimiters:

<script language="VB" runat="server">

Sub DotNetSub()
        'code here
End Sub

</script>

<%
'now call the sub
DotNetSub();
%>
Within the SCRIPT tag, you can set the language to any .NET language (VB,C#,JScript,etc.).

Also, if you want your function to write something directly onto your page, you must put it within a Response.Write(). You cannot put plain text in between the beginning and end of your function, as you could in the old ASP. The .NET format would look like this:

<script language="VB" runat="server">

Sub DotNetSub()
        Response.Write("Put your HTML and dynamic text here")
End Sub

</script>

The Request Object

The Request Object, one of the most important features of the ASP object model, has seen a few changes on the .NET platform. In the old ASP, information returned from the Request object (Request(), Request.Form(),Request.QueryString()) would be returned as an array of strings. ASP.NET will not return this as an array, but rather as one string.

For example, let's say you are passing two parameters into your .aspx page (often the case if you have a select box that allows for more than one selection), in a link like this:
  • http://www.yoursite.com/newpage.aspx?selValues=1&selValues=2
In traditional ASP, to get the second value, you would write this:
  • Request.QueryString("selValues")(2)
That won't work in .NET. First, in .NET you need to remember that all arrays are now 0-index based. Second, to access these values, you need to make a call to an explicit method to get the values:
  • Request.QueryString.GetValues("selValues")[1]
To get all of the values that have been passed into your page, you don't need to make a method call. Just code this:
  • Request.QueryString["values"]
I used Request.QueryString throught this example, but the process is the same for getting information from Request() and Request.Form().

ASP.NET and VBScript

One of the biggest changes to ASP.NET is that it no longer relies on the "pseudo-VB" language of VBScript. Instead, ASP Code is now the exact same language as VB.NET. There are many differences between Visual Basic 6.0 and VB.NET -- too many to cover in this tutorial. However, I will give you a brief overview of some of the more important changes.

First, you can no longer use the default properties of an object, unless it is indexed. So, for example, let's say that you had a recordset object named "RecordSet". You would have to change this code:
  • RecordSet("Name")
Instead, you must make an explicit reference to the property:
  • Recordset("Name").value
The second change is that arguments are now, by default, passed ByVal, not ByRef. You can still pass variables by reference, you just need to explicitly declare that by placing the keyword "ByRef" before the variable name in your function declaration:
  • DotNetSub(ByRef refVariable)
The third major change is that ASP.NET no longer uses the keywords SET or LET when assigning values to OBJECTS. Instead, when you are creating an object, you assign it a value the same way you would with any other variable. Let's say you want to create a Connection object. After using dim ("dim connObj") you would assign it a value this way:
  • connObj = Server.CreateObject("ADODB.Connection")
The final major revision to VB.NET code is that you must now use parentheses when making a call to a Sub. In other words, when making a call to SUB don't treat it any differently than a function:
  • DotNetSub()

Transactions

The process of handling transactions -- the ability to "undo" a series of programmatic actions if any part of it fails -- has seen some changes in the .NET platform. If your .aspx page is going to handle transactions, you must first enable its support:
  • <% Transaction="Required" %>
The Transaction property has four possible values:

Required Requires a transaction -- either continues an existing one or creates a new one
RequiresNew Requires a transaction -- will force a new one
Supported If there is a transaction, it will continue it -- otherwise, it will not have a transaction
NotSupported ObjectContext will be created without a transaction, no matter what

You must use the System.EnterpriseServices.ContextUtil object to maintain (or abort) transactions:
  • ContextUtil.SetComplete()
Or:
  • ContextUtil.SetAbort()

Threads

Older versions of Visual Basic (5.0 and 6.0) used Single Threading Apartments as the default for its components. VB.NET (and ASP.NET which relies on VB.NET) uses Multi-Threading. This can have a huge impact on the performance of your pages if you are relying on older COM Components that have been developed in eariler versions of Visual Basic -- one of the problems is that it screws up the marshalling process that is crucial to the way that COM objects operate. You have two options here: rewrite your old COM components and make them .NET compatible, or notify your ASP.NET pages that your components are Single Threaded:
  • ASPCompat = "true"
However, even if you do this you will be forced to endure a period of severe frustration, as you will find that many of your older pages will dramatically decrease in performance. In the long run, if you are committed to getting the best performance out of .NET, you are going to have to go back and rewrite your COM code.


Want to discuss this article, or other development issues? Visit our message boards!

Or contact us directly with a comment or question on this article: click here !
armbrustconsulting.com