What's New in ASP.NET Web Pages

Article
10/15/2014

This topic describes important changes and new features added to ASP.NET Web pages for version 2.0 of the .NET Framework.

Page Appearance

ASP.NET pages have been enhanced to provide you with more options to control their appearance.

Master Pages

You can create consistent layout for multiple pages by creating a master page and individual content pages. The master page defines the layout, navigation, and controls that you want to share among the pages in your Web application. The master page can also contain code that applies to all pages. You can then define content pages that reference the master page and merge their content with the master page at run time. For more information, see ASP.NET Master Pages Overview.

Themes

You can now use ASP.NET themes to style Web pages. A theme is a collection of control property settings (referred to as skins), style sheets, and graphics that you can apply as a unit to a page or Web site. Themes enable you to define styling that can be applied to a set of pages, and can be changed as a group. For more information, see ASP.NET Themes and Skins Overview.

Page Behavior

ASP.NET Web pages have been enhanced with new features that give you improved control over how the page functions.

New Code-Behind Model

ASP.NET continues to support the single-file model in which code is embedded in a script block in the .aspx page. In addition, a new code-behind model has been introduced, which is simpler than the code-behind model that was used in earlier versions of ASP.NET. The new code-behind model is based on partial classes, which enables you to define a portion of a class, such as the event handlers, and keep the code in a separate file. The partial-class file is compiled as part of the .aspx page.

Note
The new code-behind model is available only with .NET languages that support partial classes. Some languages, such as J#, do not support partial classes.

For more information, see What's New in the ASP.NET Web Page Model.

View State and Control State

In version 1.1 of ASP.NET, view state is used to store control state information, the content of controls, and application data. Developers sometimes want to disable view state to reduce the amount of data sent during a round trip. However, in ASP.NET 1.1, disabling view state causes some controls to stop functioning properly.

In ASP.NET version 2.0 you can disable view state without breaking control behavior. Controls that require state persistence across postbacks store their own data in a private store, which is referred to as control state. Control state does not store the entire content of the control. For example, the GridView control does not store the contents of all rows in control state. Instead, control state is used only to store the minimal information that is required by the control to function across postbacks, which reduces the size of the page.

As in earlier versions of ASP.NET, if you disable view state, you must regenerate control content that is generated dynamically. For example, if you are binding controls to data, when you disable view state, you must rebind the controls to data on each postback.

For more information, see ASP.NET View State.

Managing View State Size

By default, all view state information is stored in a single hidden field in the page. If a hidden field becomes too large, some proxies and firewalls will prevent the page from being posted. To prevent this problem, you can specify the maximum amount of data to store in a view state hidden field. If the view state information exceeds the specified limit, the page automatically creates additional view state hidden fields and splits the information across the fields. The split and reassembly of the view state fields is done automatically by the page.

Persisting Page State

In ASP.NET version 2.0, you can now create your own classes to persist page state. By default, pages will invoke instances of the PageStatePersister class that store information in a hidden field on the page, as in version 1.1 of ASP.NET. Pages that are used with mobile devices instead store page state in session state to reduce page size even further. By creating a class based on the abstract PageStatePersister class, you can create your own mechanism for saving page state.

Rendering XHTML

By default, ASP.NET pages and controls render markup that conforms to XHTML standards. You can disable XHTML rendering if it would cause your existing applications to stop functioning properly. For details, see ASP.NET and XHTML.

Cross-Page Posting

As in earlier versions of ASP.NET, Web pages post back to themselves when users click a button or other control that posts. You can now configure pages to post to another ASP.NET Web page, which is useful for creating multi-page forms. On the target page, you can get information from the source page, such as the values of controls. For more information, see Cross-Page Posting in ASP.NET Web Pages.

New Page Life Cycle Stages

In order to accommodate new features, such as master pages and themes, the Page class supports new methods and events that are available during the life cycle of a page. For example, the Page class now supports a PreInit event that you can use to set themes or master pages dynamically. For more information, see Page.

You can now access the page header directly from server code. The Page object exposes a Header property that gives you an easy way to manipulate linked style sheets, the style element, metadata elements, and the page title.

Control Focus

Using new methods on the Page class (SetFocus or on individual controls (Focus), you can manage which control in the browser has the focus when the page renders. ASP.NET Web pages utilize this new functionality to provide an enhanced capability for maintaining scroll position after a postback. For details, see How to: Set Focus on ASP.NET Web Server Controls.

Creating Client Script

The methods for injecting client script into a page (for example, RegisterStartupScript) have been moved from the Page class to a new ClientScriptManager class and have been enhanced. The methods on the Page class are still available for backward compatibility, but they are deprecated. The new versions of these methods include a parameter that enables you to designate the type with which the script is associated. This enables you to create separate script blocks for the page and user controls.

For more information, see Programming ASP.NET Web Pages with Client Script.

Browser-Specific Property Filtering

You can now create browser filters for property values. This enables you to specify different property values on the same control for different browsers. For example, you can specify that the Text property of a Label control has one value for Internet Explorer and a different value (perhaps a shorter string) for other browsers. You can filter property values based on classes of browsers (for example, Mozilla-class browsers, Ericksson, or Nokia) or by specific major browser release or major and minor browser releases (for example, Internet Explorer version 4, or Ericksson P800 and P800R101). For more information, see ASP.NET for Mobile Devices.

Client Callbacks

You can perform server processing in a page without requiring a full round trip. This enables you to request server-based information from client script. For more information, see Implementing Client Callbacks Without Postbacks in ASP.NET Web Pages.