Advertisements

From ASP to ASP.NET... Painlessly!

Introduction

This article is not a tutorial on ASP.NET. You can find many of those on the web and they usually focus too much on the fundamental concepts while leaving out practical examples. Often what you are really looking for are arrows that point us immediately to the core of the matter and then leave the analasis of the details to us to be done later. The steps you must take to move from ASP to ASP.NET are not complicated and there aren't really that many of them! Above all, if we "think" and write OOC (Object Oriented Code), even while we're still using ASP, the possibilities offered by the new framework are quite intoxicating!

The Necessary Ingredients

Here, therefore, is a directory of the steps to follow in order to pass to ASP.NET after that the installation of the .NET Framework and VS.NET has been completed:

• Create a copy of the directory (MYSITE) containing the existing ASP web application and rename it (MYSITE_NET).

• Make the new /MYSITE_NET directory a virtual directory through IIS or PWS.

• Open VS.NET and create a new empty Web project (/MYSITE_NET/myPrjNet.vbproj).

• Add to the new project the asp files from our web application. To do this, from the "Solution Explorer" window, right-click on myPrjNet.vbp and choose "Add" -> "Add Existing Item..." The file select window will open in order for you to select the files - to view ASP files select the filter "Web Files."

Start the .NET Application

The first step in migrating the application is to set the default start page (the first file that is executed when we run the application). You can do this by right-click on the appropriate file in the "Solution Explorer" window and selecting "Set As Start Page." For example: /MYSITE_NET/default.asp. At this point, we can already execute our application by starting it (without debugging) by pressing CTRL+F5. As long as your browser is in "online" mode and your local web server is started it should work as always.

Surprised? ASP.NET is perfectly compatible with ASP and the two co-exist quite well together. If we experiment and try renaming our ASP files to ASPX things change a little. Before doing this however, we run into another wonder of the VS.NET environment:

The Debugger!

If you tried to execute the application in Debug Mode (F5 instead of CTRL+F5), you will probably receive a message saying that you need to enable debugging in order to see the line causing the error. To get around this problem you need to modify the web.config file forr your project. Instead of writin it by hand, you might want to search for one:

Start - > find file - > web.config

Find one and copy (do not move!) it to the root of your application (/MYSITE_NET/web.config) and try again.

If you open a web.config file (an XML-formatted text file) with a text editor you'll discovered lots of interesting settings, but I'll leave it to the reader to explore the file. The setting we're interested in is the compilation tag. If it exists, set it's debug attribute to True. If it doesn't exist, you can simply add it:

<compilation debug="true" />

Another way to set up side-server debugging it to set the option for individual files (ie: not the entire application) by editing the first line in the appropriate file. Simply add a debug attribute to the page declaration:

<%@ Page Language="VB" Debug="true" %>

In this line of code appears one of the new, fundamental, directives of ASP.NET: @Page, which is described in a successive paragraph.

Important: The execution of applications in debug mode can cause an overload of the server's memory and a reduction in performances. Be sure that the you disable debug mode before going live with a page or site!

Rename MyForm.asp To MyForm.aspx

At this point we can try the experiment mentioned previously: we'll choose an ASP file and tell Visual Studio to exclude it from the project. You do this by right-clicking on the file in the "Solution Explorer" window and selecting "Exclide From Project." Once the file is excluded, we'll rename it and then re-add it as we did originally. You'll most likely see a message something like this:

"There is no class file in the project associated with the Web Form 'MyForm.aspx'. Create a new class file now?"

You'll probably want to select the "Yes" button. The framework, at this point, will do two things:

1. It will insert the following line at the top of MyForm.aspx:

   <%@ Page CodeBehind="MyForm.aspx.vb" Language="vb" Inherits="myPrjNet.MyForm">

   This directive to the compiler (Yes... ASP.NET pages are compiled and not interpreted! Explaining the process is beyond the scope of this article, so if you're interested I recommend you read the supplied documentation from Microsoft.), that is included in most all ASP.NET files provides a number of pieces of information so the compiler can compile the page correctly. The main parameters are:

   • [CodeBehind]: Where to find the code, that is the class, that is "behind" the ASPX page. In our sample case it would MyForm.aspx.vb.

   • [Language]: The language used: VB, C#, etc...

   • [Inherits]: The parent class from which our page inherits attributes and methods. Almost always defined in the codebehind file.

   • [Debug]: Indicates whether the page should be executed in debug mode. Must be either True or False. As we've already mentioned, this option does not have to be set in the individual file. You can set it in the web.config file for all pages in the project.

   
    

2. It will generate the file MyForm.aspx.vb:

   Effectively what we want to do is to move nearly all of the code written in the original page (MyForm.asp) to the new code-behind file (MyForm.aspx.vb). In particular, all the Functions and Subs defined in the original asp file will now become methods of our class (after we've added the correct modifier - Public, Protected. or Private). All classes defined in this way derive from the parent class: System.Web.UI.Page and possess two main Private methods: Page_Init() and Page_Load(). More information on the parameters and use of these methods can be found on the web and in the .NET Framework documentation.

   What's New in VB.NET

   After you've moved all the event handlers and code to the MyForm.aspx.vb file, the "operating" code, that is the code remaining between the <body> tags should be all that remains in the ASPX page. If we now execute the project in Debug mode we will discover the power of this setup. Most of the common errors you'll run into when migrating are results of the changes from VB to VB.NET:

   • All variables must be declared and eventually typed. The "Variant" type no longer exists. Unspecified variables default to the generic "Object."
   • All method calls require parentheses. It is not possible, as an example, to have:

       Response.Write "Hello .NET!"

     Instead you'll need to write:

       Response.Write("Hello .NET!")

   • The instructions Set and Let are no longer necessary (everything is now an object!).
   • Some of the weird VB constructs have been changed:

       While <expression>
    [...]
  Wend
 

     becomes:

       While <expression>
    [...]

   Session Variables Between ASP and ASP.NET

   Obviously it is not necessary to convert all your ASP pages to ASP.NET As we've already mentioned, the two can inhabit the same atmosphere and can calmly co-exist. But, if we declare of variable of session scope in an ASP.NET page, it will not be visible to and ASP pages. It is therefore necessary to convert all the files which need to access these variables to ASP.NET using the method described above.

   Conclusion

   At this point you might ask yourself: "Why should I migrate to ASP.NET if my application already works fine?" There are a number of reasons: completely object-oriented programming (single and multiple inheritence, poly-morphism, encapsulation etc...) => easier maintenence, code re-use, automatic documentation from reverse engineering, the best cross-language debugger, and ASP.NET controls (which I will cover in a future article), etc...