Sankofa » ASP.NET

ASP.NET 1.X to ASP.NET 2.0 Migration Postback Problem

Ian Uy — Sun, 17 May 2009 15:40:17 +0000

ASP.NET Migration Problem

If you’ve read my previous blog post, I talked about some of the problems encountered while migrating some of our web applications from .NET 1.1 to .NET 2.0. Well, those products are now handed off to the Test Department for their routine torture.

Just a couple of days after the hand-off (Hand-off to Test or HOTT), the tester who is testing the product filed two (2) Tracks (Incident/Bug/Problem). Since I am the only developer working on the product, all of the tracks will automatically be assigned to me. The said tracks that were filed have the same “type” of problem.

When browsing for a file (Backup File / File Upload), the value of the Textbox would change back to its default value when the page re-loads.

The web application that I am supporting was originally written in .NET 1.1 using Visual Studio 2003. To migrate it to .NET 2.0, we converted the solutions to VS2005. Aside from some minor problems like RESX incompatibility and broken Calendar Controls, the Web Application worked — I thought it did.

We have a Backup Restoration Page to allow the user to restore the web application in-case of Armageddon-like circumstances. The said page basically contain 3 components:

A Read-Only Textbox that holds the path of the Backup File . This Textbox has a default value of C:\Backups\Backup.bak
A Browse button that will launch a custom page that will allow the user to browse for the Backup File. The value selected there will be posted-back to the Backup Restoration Page.
A “Restore” button to start the restoration process.

When I tried to repro (reproduce) the bug on my Virtual Machine setup, I was able to verify that the path of the Backup File is losing its value on postback. To put it more precisely, the Textbox is not retaining the correct path since it is changing back to its default value on postback.

After hours of debugging, I was no where close in determining the cause of the problem. So I did a quick search on Google and found out that this is a common problem during migration from ASP.NET 1.1 to ASP.NET 2.0.

The problem is that Microsoft changed the behavior of read-only textboxes on ASP.NET 2.0.

ASP.NET 2.0 had a design change by which a control if marked with its ReadOnly property as true, would ignore client side changes and would lose the same across postback. So if you tried modifying the text box value or add a value to the text box using Javascript you wouldnt be able to retireve the value in the code behind or simply the value will be lost across postback.

This behaviour is by design in ASP.NET 2.0 and it has been designed with the idea that a ReadOnly TextBox shouldnt be modified in the client side by a malicious code.

Microsoft has a point. What’s the point of using a Textbox if you’re going to set it to Read-Only? Why not use a Label instead?

Fortunately, we have three simple workarounds for this problem.

Use a Label instead of a Read-Only Textbox. (Heard of Borders?)
Set the Read-Only property of the Textbox to FALSE (If you don’t really need the Read-Only Property)
But if you are really insisting of using a Read-Only Textbox, then we need to “fool” ASP.NET that the Textbox is not Read-Only even if it is.

To “fool” ASP.NET, you need to set the Read-Only property of the Textbox to FALSE during design time (Using the Property Pane) then set it to Read-Only on Page Load during runtime. You CANNOT use Textbox1.ReadOnly = true. You need to set the read-only attribute using the Attribute.Add() method.

// This is part of the C# code-behind file.
protected void Page_Load(object sender, EventArgs e)
{
     TextBox1.Attributes.Add("readonly", "readonly");
}

That will solve your postback problems.

References:

Share and Enjoy:

Migration: Why Developers Hate Microsoft or Why Developers Hate Vista or My First Encounter how Microsoft can Break your Software

Ian Uy — Sun, 10 May 2009 14:13:29 +0000

Do you know how much Programmer's Blood it cost to put this tiny sticker in a Software Box?

In my previous blog post, I’ve mentioned that I’m working on a project to migrate an entire product line to Vista. What I meant by that is that I am responsible for making sure that our current product will run properly on Windows Vista. To guarantee that it is indeed Running Properly it should behave *exactly* like it behaves in Windows XP. In simple terms, my entire job security is riding on making our products compatible with Microsoft’s failed attempt at a MAC-ish Operating System and with Microsoft’s successful attempt (a first in their history) to make their operating system NOT backward compatible with older applications. So much for Raymond Chen’s camp undying obsession with backward compatibility.

This products that I’m talking about are a set of Web Applications written in ASP.NET version 1.1. This web applications are as old as Windows XP. I checked its File Modification History in our TFS repository and the last time that anyone have touched its code base is in 2005 — and that’s just for a minor code modification to fix a bug. I believe this apps were written way way back in 2004 — when I was in Third Year High School!

To make this products compatible with Vista, there are a couple of steps that had to be done. I’ll enumerate each steps and what it takes to accomplish them.

.NET Upgrade (.NET 1.1 to .NET 2.0)

Windows Vista comes pre-installed with .NET 2.0 (and .NET 3.0). Our products are running on .NET 1.1. One approach that most people will suggest is to just install .NET 1.1 on Windows Vista and everything will be perfect. Right? WRONG. Firstly, .NET 1.1 has already reached its end-of-life. Microsoft pulled support for .NET 1.1 last October 14, 2008. Although it was extended, its a sign that this technology is old enough to be replaced. Secondly, installing .NET 1.1 on a Vista machine is not as easy as you think. No, we are not lazy programmers, we just don’t want to introduce unnecessary complications to the system. We are, by the way, Software Developers.

Those Lazy Programmers

So the approach we took is to upgrade our Visual Studio 2003 solutions to Visual Studio 2005 solutions. This, in turn, will “force” the web application to use .NET 2.0. You might say, “How hard could it be? Visual Studio 2005 can convert old solutions automatically using its Upgrade Wizard. All you have to do is click next!, You lazy programmer!”. That’s correct. Upgrading the solution is no problem. Converting every file to .NET 2.0 compliant code is.

We encountered two conversion problems. The first one is relatively simple to fix. It’s a problem where the old .NET 1.1 Resource files (*.resx) were not converted to the .NET 2.0 resource files. The two resource file formats are different (the .NET 2.0 have a *.designer.cs component) and in very rare cases, the .NET 1.1 *resx files won’t work in .NET 2.0. This problem is very hard to catch since the incompatible *.resx files won’t throw a compile error. The strings just won’t be detected. But once found it was relatively easy to fix. After a day of investigation, we found out that the XML format for the resource files changed in .NET 2.0. As a simple hack (fix), we manually changed the parameters of each .NET 1.1 strings to match the .NET 2.0 parameters.

The second problem is harder to find and much much harder to fix. The problem is related to ASP.NET’s datetime picker control.

Our Calendar Control before upgrading to .NET 2.0

On our previous version running .NET 1.1, there is no problem with the datetime picker. But when we installed the .NET 2.0 version, the calendar objects are all over the place.

The Migrated .NET 2.0 Calendar Control

Two days of investigation later, we found out that the previous developer made this custom Calendar control by inheriting from .NET 1.1’s System.Web.Controls. During pre-render, he reads the rendered Calendar Control’s HTML and then does something funny with it. What he wanted to achieve is to replace the “Month” from the Calendar header (gray part) with a drop down box that contains a list of the months. So what he did is he “catch” the HTML stream from the Calendar Control and perform a String.Replace on it!

His Design Goal

The actual String.Replace command is something like this:

//szHTML = Get current HTML stream
//szCurrentMonth = Get current month from HTML
szHTML.Replace(szCurrentMonth, "

 
");

It worked fine before the migration, but somehow we broke it during migration to .NET 2.0. A further investigation of the “emitted” HTML stream from the .NET 2.0 control shows this:


.....






<

May 2009
>





Sun
Mon
Tue
Wed
Thu
Fri
Sat


26
27
28
29
30

1
2

A comparison with the “emitted” .NET 1.1 control shows this:


.....






<

May 2009
>





Sun
Mon
Tue
Wed
Thu
Fri
Sat


26
27
28
29
30
1
2

Executing the String.Replace command in the .NET 1.1 code will produce the proper output. However, Microsoft decided to upgrade the Calendar control in .NET 2.0 by adding a tooltip for each date!

Tool Tip in .NET 2.0

Since the String.Replace has no checking (this is not REGEX afterall), it also replaced the “Month” in the tooltip with the drop down box (