Converting an ASP.NET Website from
Version 1.1 to 2.0
Using Visual Studio
2005
Introduction
I recently
converted a medium-sized website
with about 40 pages from ASP.NET 1.1 to 2.0 and
decided to write an article about this effort. In
this article, you’ll find a summary of the notes I
took while going through the conversion process, as
well as some thoughts that crossed my
mind and tactical decisions I had to
make.
I think any
systems conversion should start with some critical
and objective questions that we need to ask
ourselves, before making any changes. For example:
-
Why are we
converting?
-
What will be
the benefits of conversion …
-
For the
developers?
-
For the
end-users?
-
How much time
and resources will it take?
The answers to
these questions will not only determine how we’ll
proceed with the conversion process, but more
importantly, whether or not we should embark on the
conversion
effort to begin with.
The Roadmap Ahead
Conversion of an
ASP.NET website from 1.1 to 2.0 has three
fundamental phases:
Phase 1 – Preparations,
with a focus on studying the differences between 1.1
and 2.0 (see References at the end of this article)
as well as learning about the new features in 2.0
(whether they are functionalities that were done
differently in 1.1 or new things that were not doable in
1.1)
Phase 2 – Decisions, in
order to answer the following questions:
-
Are we still
going to convert?
-
For our IDE,
are we planning to use
Visual Web Developer Express or
Visual Studio 2005?
-
As we
approach
ASP.NET 2.0, are we taking
the “Web Site” road or the “Web
Project”
highway?
-
What specific
2.0 features are we planning to implement right
away and which ones will we utilize at a later time (or
not at all)?
Phase 3 – Actions, in a
well-defined order of priority:
-
Resolve known
issues in the existing system
-
Pre-requisite
software setups
-
Overall
Conversion
-
Test and
resolve conversion errors
-
Test the
application’s functionality, while being
prepared for surprises!
-
Re-write
selected portions, using new features
-
Test
-
Deploy
Phase 1 –
Preparations
My preparation
sources were primarily from the web, with additional
reference to various ASP.NET books. One of the
interesting subjects I learned about was the
difference between a “Web Project” and a “Web Site”
in ASP.NET 2.0. Apparently, the “Web Site” model
was the sole option in the original release of 2.0,
but then the “Web Project” model to added at a later
time, in order to address special needs of systems
that are being converted from the 1.1 version.
Phase 2 –
Decisions
From my experience
in the past, the decision to convert a system might
come from various sources. For example:
-
A company
policy may mandate the conversion. This was
primarily the case during the late 90’s for the
Year-2000 compliance conversions.
-
An IT
department may initiate the conversion, when
other similar systems have been converted as
well, in order to have a homogeneous platform
for all their systems and save on necessary
resources and skill sets to support them.
-
A particular
feature in the new version is so desirable that
it would justify the entire conversion effort.
In my case, the
last one was the reason and, as I will elaborate
later, I justified the conversion effort in order to
take advantage of the new Master Pages in
ASP.NET 2.0. Therefore, my
answers to the previously stated questions for Phase
2 are:
-
Yes we still
going to convert. I believe being able to
use the Master Pages is enough reason to convert
to ASP.NET 2.0.
-
For the IDE,
although Visual Web
Developer Express is a free tool, I chose
Visual Studio 2005
in order to take advantage of every bit of help
it has to offer (as I truly believe that the
most valuable asset in a conversion effort is my
own time).
-
I did a lot
of reading on the differences between web sites
and web projects in ASP.NET 2.0 and my
conclusion was that, for an upgrade from 1.1 to
2.0, web project is a better choice.
-
As I mentioned
in my justification to convert, the only
specific 2.0 feature I implemented at the
beginning was Master Pages.
Phase 3 – Actions
Although every
situation may be different in its own unique way, I
found the following to be a logical approach (which
is pretty much the same order described in the
Step-by-step Guide):
 | Resolve any
existing / known issues and start off with a
clean system |
| Pre-requisite
software setups, including Visual Studio 2005
and the new Web Application Projects |
| The “Real
Thing” – Overall Conversion, using the
Conversion Wizard (which pops-up when you open
an ASP.NET 1.1 Project in Visual Studio 2005).
I might also add that backing up the old system
is very critical for the following reasons:
-
Because the
step-by-step instructions say so;
-
Because we'll probably need a point of
comparison for the way something was done in
1.1, prior to the global changes that will
be made by the conversion wizard;
-
Because there's a possibility (though
unlikely) that the management (or whoever is
in charge) may decide to stay with 1.1, even
after we have already started the conversion
effort.
Therefore, I
recommend even an additional backup (using any
backup method of your choice), before you get
to the point where the Step-by-step Guide asks you
to do so.
|
|
| Resolve
conversion errors (these are the things that the
wizard couldn’t resolve automatically) |
| Address the
conversion warnings (these are the things that
the wizard recommends should be changed – such
as discontinued / obsolete features) |
| Test the
application’s intended functionality, while
being prepared for surprises! I have had to
face this reality in every previous systems
conversion, and indeed this was no exception.
Here’s what happened:
|
As soon as I
navigated to some functionally-rich pages of the
converted website, I started getting some totally
unanticipated errors. To make a long story short,
after stepping through the process line-by-line, I
realized that for some unknown reason, the Page_load
was firing twice (and both times, it was not a
postback).
What did I do
next? I checked MSDN and Google and, sure enough,
there were a lot of postings about the ASP.NET 2.0
Page_load firing twice. Furthermore, they were all
pointing to the cause of the problem as being the
AutoEventWireup
that is set to True and it should be set to
False, in order to prevent the double-firing
of the Page_load event. Needless to say, I had
rejoiced prematurely, as my problematic pages
already had their AutoEventWireup set to False,
which simply meant that the source of my
double-firing problem was hiding elsewhere.
After that, I put
on my trouble-shooting hat and created a new content
page, connected it to the same Master Page, and
compared its HTML code to the code in the
problematic page which had its Page_load firing
twice.
The difference
was in the “Handles” clause. The bad page had
Handles MyBase.Load, Me.Load
while the good page had
Handles Me.Load.
I don’t know why the conversion wizard doesn’t take
care of this as it should, but now that I had
figured out the problem, I could certainly fix it
myself. (Interestingly enough, after I figured out
about the Handles clause, I also found a reference
to it on GotDotNet’s message board. So I cannot
claim to be its only discoverer.) |
|
| Re-write
selected portions of the system to the new way
of life in ASP.NET 2.0 (e.g. Master
Pages). This process, in effect, consists of
two parts: Creating Master Pages and modifying
content pages to reference to reference their
corresponding Master Page. Within each Master
Page, all you need is probably a common banner
(image) which will show up on all content pages
and one or more content place holders (main
content /
left navigation / footer). |
Also note that if
a place holder is not referenced by the content
page, it won’t be rendered at all. Therefore, if
you were thinking to create, say, two different
master pages – one with main-content and
left-navigation place holders and the other just
with main-content – you can create only
one Master Page with both place holders.
Subsequently, if a page doesn't need the
left-navigation, don't reference the left-navigation
place holder of the Master Page and it won't show up
in the browser.
Nonetheless, this
will lead to two additional questions:
1.
Do
we ever need more than one master page? It really
depends on design, architecture and complexity of
the site. If we need them, we can definitely create
them.
2.
Are
we converting all content pages to reference a
corresponding Master Page? Probably but not
necessarily! From an ASP.NET perspective, we can
have some content pages with a master page and some
without.
As for the content
pages which need to reference a Master Page, here
are the conversion steps for each:
1.
Open
the HTML Source view
2.
On
the @ Page line, before Codebehind=,
add
MasterPageFile="~/MyMP.Master" (where MyMP
is the name of Master Page)
3.
Right
after the @ Page line, remove the following
tags:
<!DOCTYPE
… >
<HTML>
<HEAD> through </HEAD> (except for any
JavaScript code / function which may be
within <script ...> </script> tags and
must be preserved)
<body …>
<form …>
4.
From
the end of the HTML page, remove the following
closing tags:
</form>
</body>
</HTML>
5.
Locate and remove any items that will be part
of the new Master Page (e.g. the banner / image at the
top of the page, which might have been coded between <asp:Image
…> and </asp:Image> tags)
6.
Back at the top of the page, below the @
Page line, insert an <asp:Content …> tag,
referencing the corresponding
ContentPlaceHolderID in the Master Page.
7.
At the end of the HTML Source, add the
closing tag </asp:Content >.
8.
Switch to the Design view, then double click
anywhere and open the Codebehind file.
9.
Change
the 1st
line of Page_Load from
Handles MyBase.Load, Me.Load
to
Handles Me.Load
and then close and save the page.
-
Test the
content pages which were converted to reference
a Master Page.
| Important
Note:
If a
content page that's linked to a Master
Page uses JavaScript (e.g. to open a
calendar pop-up window and populate a
date value),
you may get an error which reads
something like "window.opener.document.txtDate.value=..."
is null or not an object. This is
primarily caused by the fact that your
object name txtDate has been changed by
ASP.NET 2.0.
The short solution to this error would be:
-
Open the page in View Source and
find the full name for your txtDate,
which may be something like:
ctl00$MiddleContentPH$txtDate
-
Change the JavaScript references to txtDate
to its fully qualified equivalent.
For example, from
onclick ="calendarPicker('Form1.txtDate');"
to
onclick ="calendarPicker('forms[0].ctl00$MiddleContentPH$txtDate');"
-
In your web.config file, locate and
remove: <xhtmlConformance
mode="Legacy"/>
(otherwise, the above reference to
ctl00 will show-up as _ctl00, which
will be tricky to work with!)
Nonetheless, the recommended
solution for the above conversion issue is a little
more time consuming, which you may implement right away or at a
later time. For that, you should use JavaScript getElementById
instead of referencing the elements by Name.
|
-
Deployment is
the next major step in the conversion process.
In case of ASP.NET 2.0 in particular, as
described in the reference documents, there are
various compilation and deployment options to
choose from. Your site may be compiled into one
assembly or multiple assemblies and your
deployment options include pre-compile,
full-compile, updatable, etc.
-
Once your
converted site is successfully deployed, you can
feel free to choose your
subsequent enhancements, from a long list of new
features in ASP.NET 2.0, such as:
-
Improved
Master Pages (with themes, CSS, etc.)
- Personalization
- Data access
Conclusion
Like any systems
conversion process, in order to go from ASP.NET 1.1
to 2.0, you need a roadmap. This roadmap should
include (but not be limited to) planning,
acquiring
knowledge
of where you’re going and the right tools to get you
there,
and preparedness to face and overcome the
unexpected.
Good luck and
happy coding!
References
|
Pointer
Corporation