Pointer Corporation
     The Information Technology Architects
Converting an ASP.NET Website from Version 1.1 to 2.0

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):

bullet Resolve any existing / known issues and start off with a clean system
bullet Pre-requisite software setups, including Visual Studio 2005 and the new Web Application Projects
bullet 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:

  1. Because the step-by-step instructions say so;
  2. 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;
  3. 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.


bullet Resolve conversion errors (these are the things that the wizard couldn’t resolve automatically)
bullet Address the conversion warnings (these are the things that the wizard recommends should be changed – such as discontinued / obsolete features)
bullet 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.)


bullet 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:

    1. Open the page in View Source and find the full name for your txtDate, which may be something like: ctl00$MiddleContentPH$txtDate
    2. 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');"
       

    3. 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.