Practical ASP.NET

Upgrading Sites to ASP.NET 2.0/3.5

It's good news, bad news if you're upgrading an existing site to ASP.NET 2.0 or 3.5. But it can be done.

• By Peter Vogel
• 05/21/2008

Now, the not-as-good news: Bringing an ASP.NET 1.1 site up to ASP.NET 2.0 or 3.5 is...problematic.

And a lot of organizations have sites that need to be upgraded from 1.1. Many of these 1.1 sites are applications that were started in 1.1 and were still under construction when ASP.NET 2.0 came out. Short deadlines being the reality of most projects, the development teams continued in 1.1, rather than take the time to convert to the new technology. Other applications were built under 1.1 and since those applications are, you know, working, the sites were left in 1.1. For any maintenance or enhancements, developers just make their changes in Visual Studio 2005.

But now that ASP.NET 3.5 is in general release, organizations are less willing to maintain two sets of development environments. Besides, ASP.NET 2.0/3.5 has so many goodies that it's hard to resist the temptation to upgrade even if a site doesn't actually "need" to be converted.

Easy Conversions from 1.1
As with converting from 2.0 to 3.5, the first steps in converting a 1.1 site is to open the site in Visual Studio 2005/2008 and then to rebuild.

The second step is to not be disheartened by the huge list of errors and warnings that appear in your Task List. Odds are that what you're seeing in the Task List are trivial problems repeated many times. With any luck, many of your problems can be replaced with a global search and replace.

For instance, names that were acceptable in 1.1 for methods or properties may now be considered in conflict with language keywords. One of my clients had, in a 1.1 site, a table with a field named "Operator." After the table was recreated in a strongly typed dataset in .NET 3.5, the field was renamed to "_Operator." Renaming all of the references to the field was time-consuming but not difficult. Often, name-related problems can be solved by enclosing the offending term in brackets (e.g., "[_Operator]").

In addition to actual errors, you can expect to get a wide variety of warnings. Almost everything that worked in 1.1 still works in 2.0/3.5 but some functionality has been depreciated. For instance, if you've been inserting JavaScript code into your page from server-side code, all of the methods you're using still exist but are now to be called from the Page's ClientScript property.

If you've been using inheritance as part of your Web site development, then you'll need to move your base classes to the App_Code folder (you may find that Visual Studio has already done that for you). If, for instance, you had an ASPX page that provided base functionality that all the other pages on your site inherited, you'll need to move the code file for that page to the App_Code folder (you can delete the ASPX file itself).

Awkward Solutions
Some problems are less "amenable to solution." Visual Studio 2003/ASP.NET 1.1 encouraged developers to use CSS absolute positioning when dragging and dropping controls on the page (at least, it encouraged me). ASP.NET 2.0/3.5 works best without absolute positioning, causing developers to fall back on old-fashioned tables to hold controls.

You probably won't notice or care unless you decide to migrate your pages to a Master Page. At that point, you'll probably find that your controls appear to be "shifted" and you'll need to adjust your controls' positions.

In ASP.NET you could access another page in the same application as an object. Frequently, developers would pass data to the next page in a workflow or to a User Control by accessing properties or methods on the next page before transferring to it. This code was acceptable in 1.1 to load a User Control and set a public property on the User Control named CustomerId:

Dim c As MyUserControl
c = CType(LoadForm("MyUserControl.ascx"), MyUserControl)
c.CustomerId = Me.CustomerIdTextBox.Text

Frequently, developers used this technique to pass data to a page or user control before the page's Load event fired.

In ASP.NET 3.5, it's no longer possible to access the class associated with another page or user control. There are several solutions to the problem, including storing the data in a Session variable before transferring to the other page, using a querystring in the URL passed as part of calling Server.Transfer/Response.Redirect, or adding code in the destination page that reaches back to the original page through the PreviousPage property. Since ASP.NET 2.0/3.5 offers the PreInit event, which occurs before the Load event, the data can be retrieved earlier in the page's life cycle.

Having said all that, upgrading a 1.1 site to 2.0/3.5 can be surprisingly painless. For all but the largest sites, setting aside a week will probably let you do the conversion and test your application.

But, who knows? I may have missed something. Have you got any conversion "gotchas" to share? E-mail them to me at [email protected] and I'll roll them into a future column.