Practical ASP.NET

Cool New Features in ASP.NET 4

• By Peter Vogel
• 02/11/2010

This column starts a series that cherry picks some things to look forward to in ASP.NET 4. Since you can't use this stuff right now, consider this another installment of this column's evil twin brother, "Impractical ASP.NET."

In addition to looking at .NET 4 in these columns, there's other .NET 4 coverage underway, including a Language Lab article in our February issue that dives into the new QueryExtender control, and an upcoming feature article that pulls together tools related to client-side development in ASP.NET 4.

Compacting out-of-Process Session Data

I like using the Session object (I like the Cache object even better). Many developers object to the Session object because it imposes a footprint on the server even when a user isn't requesting a page. In ASP.NET 4 the sessionState tag in the web.config file now has a new attribute called compressionEnabled that causes serialized to data to be automatically compressed. Here's what it looks like:

<sessionState
    compressionEnabled="true"...

Of course, Session data is only serialized if you're using a state server (where mode is set to "StateServer") or a database (mode="SqlServer"). But in those scenarios, this option will lower the impact of the user's footprint when storing data in the Session object -- provided you're willing to spend the CPU cycles to compact and un-compact your data.

Permanently Redirecting a Page

It would be wonderful if we never changed the URLs for our pages. However, in the real world that doesn't happen. Pages move around. Rather than let users get 404 errors when requesting a page using a URL that's worked in the past, ASP.NET programmers often put a Response.Redirect in the Page Load of the old page and have that Redirect send the user to the new location of the page.

In ASP.NET 4, you can now use the Response.RedirectPermanent method in the same way. RedirectPermanent issues HTTP 301 messages which signal to the client that this is a permanent redirection. Provided the client recognizes 301 messages, the client will automatically substitute the new URL for the old URL whenever the user requests the old URL, skipping the trip to the old location.

Alternatively, you could use Routing, which eliminates this problem. Implementing routing is much simpler in ASP.NET 4 and I'll cover that topic in a later column.

Control-Level Changes

Probably the most important change to existing controls is invisible: Many controls will be generating different HTML in ASP.NET 4. Partially this is a move to produce HTML that is more complaint with XHTML 4.0; partially it is an effort to produce HTML that CSS authors (i.e. not me) will find easier to style. Overall, there's a sharp reduction in the number of table tags being produced. However, if you have code that's dependent on the old HTML format, you can add this element to your config file to keep the old HTML:

<pages controlRenderingCompatibilityVersion="3.5"/>

In the past, if you wanted to reduce the size of a page's ViewState, you considered setting the EnableViewState property on the Page to False. However, that disabled ViewState for all the controls on the page, and usually there were some controls that needed the ViewState. The alternative was to disable ViewState on each control where you didn't need it -- typically most of the controls on the page. Now in ASP.NET 4, you can disable ViewState for the Page and set EnableViewStateMode to Enabled on the controls where you actually need ViewState.

Next week, I'm going to look at a new feature that's tied to IIS 7.5 running on Windows 7 or Windows Server 2008 R2 (the 64-bit version) rather than ASP.NET 4. So, provided you have the right Web server, you can use this feature with your existing ASP.NET 2.0+ sites. But the feature is still in beta, so prepare yourself for more "Impractical ASP.NET."