ASP.NET 2.0: What Matters, What Doesn’t

Back Draft


ASP.NET 2.0: What Matters, What Doesn't


By Jonathan Goodyear


The Whidbey cat is finally out of the bag and the alpha release is in circulation. So now's a good time to assess which features of ASP.NET 2.0 are really going to impact your development, and which don't really do anything more than give the marketing types padding for the new feature list.


Before I get started, I'd like to point out that I will only be discussing direct features of ASP.NET. Inline IntelliSense in Visual Studio .NET is a fantastic new feature that I'm already addicted to, but that is a feature of the IDE, not the platform. I'm also not going to discuss the new ADO.NET features (of which there are plenty). Perhaps I'll cover that in an upcoming article. Lastly, this article is not meant to be an introduction or tutorial on the new ASP.NET 2.0 features. For that, please refer to the book A First Look at ASP.NET v2.0 by Alex Homer, Dave Sussman, and Rob Howard (Addison-Wesley).


Complete Backward Compatibility

Let's get this one out of the way right off the bat, because I think it is perhaps the most important thing that Microsoft is doing with ASP.NET 2.0. Very few companies dare to pledge that their new product will be completely backward compatible, but that is exactly what Microsoft has done. Don't underestimate the importance of this. I'm looking forward to using a lot of the new ASP.NET 2.0 features, but not if I have to struggle just to get my existing Web applications to compile. I applaud Microsoft for seeing the need to avoid breaking existing interfaces, like it did between ASP.NET 1.0 and 1.1 (though the changes were not significant). For universal backward compatibility to become a reality, though, we all need to help out. When the ASP.NET 2.0 Beta is released to the general public, install it on a server, test your existing Web applications on it and report any problems to Microsoft as soon as possible. Microsoft does more software testing than perhaps any other company on earth, but even they can't catch everything. This is one time when waiting for a production release can potentially hurt you.


SQL Cache Dependencies

An almost universal demand exists for a mechanism to invalidate cached pages and data based on database changes. ASP.NET 2.0 delivers the goods, but not as well as I had hoped. If you upgrade your SQL Server database to the Yukon release, you will be able to assign SQL cache dependencies at row-level granularity (actually, based on the results of a SqlCommand). This will come as a welcome addition to my development toolbox.


Unfortunately, if you stick with SQL Server 2000, you will only be able to set SQL cache dependencies at the table level. For most purposes, this solution is pretty inadequate. Imagine every cached product page on your Web site getting invalidated each time your Products table gets updated. Not pretty. You'll definitely need to plan your database schema carefully if you are going to use the SQL Server 2000 SQL cache dependency model. In Microsoft's defense, several core architecture changes needed to be made to enable the granularity offered by Yukon, but that still doesn't make the disappointment any less poignant for developers who won't be upgrading to Yukon any time soon.


Unified Control and Adapter Architecture

One of the bummers about ASP.NET 1.x is that you need to use a separate set of server controls for mobile devices (as part of the Microsoft Mobile Internet Toolkit). ASP.NET 2.0 has consolidated all of these controls into a unified control toolbox that dynamically determines how to service any device on which they are displayed. I definitely see the value in only having to learn a single set of server controls, but I still don't think that many developers will design interfaces that are meant to service more than one device type. The type and amount of content that you typically display varies too greatly from device to device. Instead, I think developers will still design separate gateways into their Web applications targeted at major device groups (e.g. pc, pda, and phone), but will now be able to enjoy the convenience of using a single toolset. A definite plus, but not the panacea that Microsoft would have you believe.


Templates, Themes, and Skins

Many developers wonder why Microsoft didn't think to build a page template architecture into ASP.NET 1.x. Actually, they did, but they didn't have time to implement the feature - until now. Partial classes (a new feature implemented by the .NET Framework) provides the key to Microsoft's near-perfect page template implementation (called Master Pages). I especially like the ability to create nested page templates, so you can have your Web application pages utilize your application-specific Master Page, which in turn utilizes the corporate Master Page. The Visual Studio .NET Whidbey IDE adds an even more pleasant page template experience by showing you what your completed page will look like once all Master Pages have been applied to it, but even the template architecture by itself is a thing of beauty.


Along the same lines of applying a universal user interface experience, Microsoft has created Themes and Skins. Skins allow you to assign common named appearance traits for server controls; Themes are named groups of Skins assembled together to form a distinct user interface experience. Although Themes and Skins are a welcome enhancement in ASP.NET 2.0, to reduce the massive clutter and repetitive UI properties on server controls, much of the same functionality can be achieved using Cascading Stylesheets. Themes and Skins carry additional value, however, in that they are tailored to server controls themselves (and not their HTML rendered counterparts), as well as when they are used in conjunction with the Personalization engine in ASP.NET 2.0.



Speaking of Personalization, the Personalization engine is my personal favorite feature of ASP.NET 2.0. Not only does it give you access to persistable, strongly-typed data about each user (even anonymous ones) that visit your Web application, but it is also built on top of the new Provider Design Pattern (as are the Roles, Membership, and Site Counters features of ASP.NET 2.0, to name a few), so you can customize its behavior according to your own whims if you don't like the behavior that comes out of the box. I also think it is incredibly powerful to be able to customize the Personalization features simply by changing the contents of the <Personalization> element of the machine.config or web.config file. You can also group the properties of your custom Personalization class to minimize the number of requests that ASP.NET makes to your Personalization data store (e.g. SQL Server and Access support are provided out of the box).


Refined Management Utilities and Management API

Most Web developers had an instant attraction to ASP.NET 1.x, but it had a love/hate relationship with hosting companies and corporate IT support staff. They loved the power, scalability, and stability that ASP.NET 1.x offered, but little was offered in the way of administration tools. Pretty much everything had to be hand-edited in various XML configuration files. ASP.NET 2.0 offers several Web-based management utilities and an IIS MMC snap-in. In a vacuum, those features alone would be adequate, but nothing to write home about. The true power, though, is in the Management API, which allows developers and/or administrators to programmatically control everything that is configurable using the XML configuration files. This opens the doors to the development of custom administration tools that are tailored to the needs of corporate IT environments, and especially hosting companies. ASP.NET 2.0 also implements many new features that are hosting-company friendly, such as the ability to restrict file upload sizes and file upload locations.


Portal Framework (Web Parts)

The portal features of ASP.NET 2.0 are rather intriguing in that they are directly integrated with the work that is being done by the SharePoint Portal Server team at Microsoft. Although I don't consider the portal features to be essential to the success of ASP.NET 2.0, I do think they are an immense time saver if you want to implement features such as maximizing/minimizing and drag and drop in your Web applications. If your company is going to be rolling out a portal application, then Web Parts will serve you well, but I'd be willing to bet that a very small percentage of Web developers will actually build them.


New Server Controls

With ASP.NET 2.0 comes a plethora of new server controls to add to your toolbox. Some are more useful than others. For instance, I think that the ImageMap control and DynamicImage control (in conjunction with the Image Generation Service) will be extremely useful. The addition of scrollbars to the Panel control was a nice touch as well.


On the other hand, some of the new controls are not really that necessary. For example, I can appreciate the fact that Microsoft felt the need to introduce a new, more powerful grid control (named GridView). After all, DataGrid hacking has practically become a full contact sport. Anyone building a powerful enterprise Web application, though, is going to want to reach for a grid control from a third-party vendor like Infragistics ( Third-party vendors live and die by the quality and feature richness of their components, so they spend the time to make them insanely more powerful than anything Microsoft is going to provide out of the box. I suspect that this reasoning explains why Microsoft didn't build a charting control in ASP.NET 2.0. Good call, in my opinion.


Microsoft has done a lot of good work with creating new Validator controls, implementing validation groups to allow more than one distinct operation to happen on a Web page without Validator conflicts and adding the ability to set focus to a particular control when a Validator fails. On the control development front, I think that the ability to embed resources (like images) directly in the assembly will reduce control dependency issues, like those suffered by many of the major control vendors.


ASP.NET Page Behavior

Microsoft has added four new events to the ASP.NET Page LifeCycle, namely LoadComplete, PreInit, PreLoad, and PreRenderComplete. A couple of these were implemented to enable features in some of the new server controls, while a couple others were implemented just to make life easier on the developer. I've said several times before, however, that you shouldn't place heavy reliance on events in the Page LifeCycle to get things done in the right order. Rather, the User Controls and Server Controls on your page should broadcast their own custom events that other User Controls and Server Controls subscribe to. In most cases, you - instead of the ASP.NET Runtime - can dictate the order of events.


Client-side postbacks seem like a great new feature at first, but in reality, they are just a packaged implementation of the XmlHTTP component that has been available for some time now in Internet Explorer. There are actually several examples on the Web that show how to get the same functionality in ASP.NET 1.x, but it's nice to see that Microsoft has packaged it all up in a standardized way that reduces that amount of custom code that you need to write. The new simplicity of it may actually prompt me to use it in some of my Web applications.


Cross-page posting is one of my favorite new features of ASP.NET 2.0. Any Web site that implements a login form or newsletter sign-up form will appreciate the ability to determine the destination of a postback based on the button that is clicked (like we used to have in classic ASP). This is definitely the case of Microsoft giving us back something that it took away when we all transitioned to ASP.NET.


Site and Page Counters

ASP.NET 2.0 sports a beefed up AdRotator control that can use a non-XML data source as well as track impressions and click-throughs. There is also a complete engine for tracking site and page impressions. I think that Microsoft's money could have been put to much better use, though, because there isn't really anything here that couldn't be implemented before with a relatively little amount of code. Also, anybody who is serious about tracking Web statistics is going to buy a packaged application to do it, such as WebTrends ( or LiveStats (


Data Source Controls

I have very mixed feelings about the new Data Source Controls in ASP.NET 2.0. At first they seem like a pretty neat way of creating solutions that involve databinding in a completely declarative manner. I mentioned in my October 2003 BackDraft column that in the future, programming would move to a more declarative architecture, and you can see those beginnings here. Microsoft is taking even greater strides toward declarative programming with its implementation of Extensible Application Markup Language (XAML) in the upcoming Longhorn operating system. However, I think the Data Source Controls are oversimplified for many production business uses. For instance, many of them (such as SqlDataSource, AccessDataSource, and OleDbDataSource) advocate the usage of a two-tier application development model with no business logic layer.


The ObjectDataSource control, which allows data to be supplied via custom business objects, is the only data source control I would consider using, and even it comes with limitations. Sometimes the determination of parameters to a data source is more complicated than just hard-coding it or grabbing the value from a control on the page, a cookie, or a querystring parameter. In that case, you're back to using custom code, which negates the benefit of using a control that is meant to be purely declarative. Databinding wasn't all that difficult in ASP.NET 1.x, so I don't think that the data source controls really buy you very much in the way of increased productivity.


Obviously, one opinion column is not enough room to adequately discuss the features and ramifications of such a large platform version upgrade. The most important thing is to keep Microsoft aware of the features that you want them to implement. Even Microsoft has finite development resources, so the more noise you make, the quicker you'll get what you want. Great things are on the horizon. My anticipation is as strong as ever.


Jonathan Goodyear is president of ASPSoft (, an Internet consulting firm based in Orlando, Fla. He's a Microsoft Certified Solution Developer (MCSD) and author of Debugging ASP.NET (New Riders). Jonathan also is a contributing editor for asp.netPRO. E-mail him at mailto:[email protected] or through his angryCoder eZine at




Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.