Five Reasons to Jump on the ASP.NET 1.1 Bandwagon
Dino Esposito is with Wintellect.
It's known that the .NET Framework version 1.1 is a minor upgrade with a relatively limited set of changes and updates. The stars in the what's-new list of version 1.1 are technologies that were already available as separate downloads such as the Oracle and ODBC .NET data providers and the ASP.NET mobile controls. In addition, the documentation has been revised and enriched with more examples and more clear explanations. If you look at the .NET Framework 1.1 from a technical point of view, you will not find many new features, but a lot of bug fixes and performance optimizations still make the new platform a recommended upgrade.
In this article, I focus on ASP.NET 1.1 and review a few programming related aspects that mark the difference between ASP.NET 1.0 and ASP.NET 1.1. You shouldn't look at them as a sort of top-five list of hot changes; rather you should take them as the gist of the changes that you find in the newest version of the ASP.NET platform.
Before I start listing the changes in ASP.NET 1.1, a fundamental statement should be made about the compatibility between the new and old platform. ASP.NET 1.0 and ASP.NET 1.1 can work side-by-side. Side-by-side doesn't mean that true interaction takes place between applications and components written for a particular version of the platform. Instead, side-by-side execution simply indicates that an ASP.NET application can choose the environment in which it wants to run. As a result, you can have applications running under the 1.0 and 1.1 runtime at the same time. In no way, do the runtime environments conflict with each other.
This said, let's go with five examples of improvements in ASP.NET 1.1.
#5—Reading Values from List Controls
The ASP.NET framework provides a few list controls such as DropDownList, ListBox, CheckBoxList, and RadioButtonList. All these controls inherit from a common parent class named ListControl. The ListControl control class provides ad hoc properties to handle data binding and to manage item selection—in particular, SelectedIndex and SelectedItem. The former returns the 0-based index of the currently selected item (if any), whereas the latter returns the selected element as an object of type ListItem.
As you can see, there's no direct way to access the currently selected value. Of course, since you have access to the object that represents the selected item, you can obtain the current value using the Value property.
string theValue = list.SelectedItem.Value;
In ASP.NET 1.1, there's a more direct property—the SelectedValue property.
string theValue = list.SelectedValue;
In terms of implementation, the two solutions are nearly identical.
#4—The ValidateRequest Property
The @Page directive features a new boolean attribute named ValidateRequest. The attribute helps in the prevention of cross-site, one-click attacks and indicates whether request validation should occur. If ValidateRequest is set to true, ASP.NET checks all input data against a hard-coded list of potentially dangerous values. For example, if the page contains an input field with some HTML text embedded, the attribute causes ASP.NET to throw an exception during the postback processing. ValidateRequest is enabled for all pages but can be disabled both at the application level (in the <pages> section of the web.config file) and for the individual page. ValidateRequest is built to block script injection attacks but it should be clear that it is anyway a small line of defense. Much better than leaving ValidateRequest on it would be to carefully validate any input your application receives from clients.