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:
It will insert the following line at the top of MyForm.aspx:
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.
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>
[...]
End While
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...
