|
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
For further information, please refer to our feedback
page.
|