Since ASP.NET 1.0 was released, output caching has enabled developers to store the generated output of pages, controls, and HTTP responses in memory. On subsequent Web requests, ASP.NET can serve content more quickly by retrieving the generated output from memory instead of regenerating the output from scratch. However, this approach has a limitation — generated content always has to be stored in memory. On servers that experience heavy traffic, the memory requirements for output caching can compete with memory requirements for other parts of a Web application.

ASP.NET 4 adds extensibility to output caching that enables you to configure one or more custom output-cache providers. Output-cache providers can use any storage mechanism to persist HTML content. These storage options can include local or remote disks, cloud storage, and distributed cache engines.

Output-cache provider extensibility in ASP.NET 4 lets you design more aggressive and more intelligent output-caching strategies for Web sites. For example, you can create an output-cache provider that caches the "Top 10" pages of a site in memory, while caching pages that get lower traffic on disk. Alternatively, you can cache every vary-by combination for a rendered page, but use a distributed cache so that the memory consumption is offloaded from front-end Web servers.

You create a custom output-cache provider as a class that derives from the new OutputCacheProvider type. You can then configure the provider in the Web.config file by using the new providers subsection of the outputCache element, as shown in the following example:

<caching>
  <outputCache defaultProvider="AspNetInternalProvider">
    <providers>
      <add name="DiskCache" 
          type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>
    </providers>
  </outputCache>
</caching>

For more information and for examples that show how to configure the output cache, see outputCache Element for caching (ASP.NET Settings Schema). For more information about the classes that support caching, see the documentation for the OutputCache and OutputCacheProvider classes .

By default, in ASP.NET 4, all HTTP responses, rendered pages, and controls use the in-memory output cache that is in the previous example (where the defaultProvider attribute is set to AspNetInternalProvider). You can change the default output-cache provider used for a Web application by specifying a different provider name for defaultProvider.

In addition, you can select different output-cache providers for individual control and for individual requests. The easiest way to choose a different output-cache provider for different Web user controls is to do so declaratively by using the new providerName attribute in a page or control directive, as shown in the following example:

<%@ OutputCache Duration="60" VaryByParam="None" 
    providerName="DiskCache" %>

To specify a different output cache provider for an HTTP request, you override the new GetOutputCacheProviderName method in the Global.asax file to programmatically specify which provider to use for a specific request. The following example shows how to do this.

public override string GetOutputCacheProviderName(HttpContext context)
{
    if (context.Request.Path.EndsWith("Advanced.aspx"))
       return "DiskCache";
    else
        return base.GetOutputCacheProviderName(context);
}

Some Web applications must load large amounts of data or must perform expensive initialization processing before serving the first request. In earlier versions of ASP.NET, for these situations you had to devise custom approaches to "wake up" an ASP.NET application and then run initialization code during the Application_Load method in the Global.asax file.

To address this scenario, a new application preload manager (autostart feature) is available when ASP.NET 4 runs on IIS 7.5 on Windows Server 2008 R2. The preload feature provides a controlled approach for starting up an application pool, initializing an ASP.NET application, and then accepting HTTP requests. It lets you perform expensive application initialization prior to processing the first HTTP request. For example, you can use the application preload manager to initialize an application and then signal a load-balancer that the application was initialized and ready to accept HTTP traffic.

To use the application preload manager, an IIS administrator sets an application pool in IIS 7.5 to be automatically started by using the following configuration in the applicationHost.config file:

<applicationPools>
    <add name="MyApplicationPool" startMode="AlwaysRunning" />
</applicationPools>

Because a single application pool can contain multiple applications, you specify individual applications to be automatically started by using the following configuration in the applicationHost.config file:

<sites>
  <site name="MySite" id="1">
    <application path="/"
        serviceAutoStartEnabled="true"
        serviceAutoStartProvider="PrewarmMyCache" >
        <!-- Additional content -->
    </application>
  </site>
</sites>

<!-- Additional content -->

<serviceAutoStartProviders>
    <add name="PrewarmMyCache"
        type="MyNamespace.CustomInitialization, MyLibrary" />
</serviceAutoStartProviders>

When an IIS 7.5 server is cold-started or when an individual application pool is recycled, IIS 7.5 uses the information in the applicationHost.config file to determine which Web applications have to be automatically started. For each application that is marked for preload, IIS7.5 sends a request to ASP.NET 4 to start the application in a state during which the application temporarily does not accept HTTP requests. When it is in this state, ASP.NET instantiates the type defined by the serviceAutoStartProvider attribute (as shown in the previous example) and calls into its public entry point.

You create a managed preload type that has the required entry point by implementing the IProcessHostPreloadClient interface, as shown in the following example:

public class CustomInitialization : 
    System.Web.Hosting.IProcessHostPreloadClient
{
    public void Preload(string[] parameters)
    {
        // Perform initialization.
    }
}

After your initialization code runs in the Preload method and after the method returns, the ASP.NET application is ready to process requests.

Content in Web applications is often moved over the lifetime of the application. This can lead to links to be out of date, such as the links that are returned by search engines.

In ASP.NET, developers have traditionally handled requests to old URLs by using the Redirect method to forward a request to the new URL. However, the Redirect method issues an HTTP 302 (Found) response (which is used for a temporary redirect). This results in an extra HTTP round trip.

ASP.NET 4 adds a RedirectPermanent helper method that makes it easy to issue HTTP 301 (Moved Permanently) responses, as in the following example:

RedirectPermanent("/newpath/foroldcontent.aspx");

Search engines and other user agents that recognize permanent redirects will store the new URL that is associated with the content, which eliminates the unnecessary round trip made by the browser for temporary redirects.

By default, ASP.NET provides two options for storing session state across a Web farm. The first option is a session state provider that invokes an out-of-process session state server. The second option is a session state provider that stores data in a Microsoft SQL Server database.

Because both options store state information outside a Web application's worker process, session state has to be serialized before it is sent to remote storage. If a large amount of data is saved in session state, the size of the serialized data can become very large.

ASP.NET 4 introduces a new compression option for both kinds of out-of-process session state providers. By using this option, applications that have spare CPU cycles on Web servers can achieve substantial reductions in the size of serialized session state data.

You can set this option using the new compressionEnabled attribute of the sessionState element in the configuration file. When the compressionEnabled configuration option is set to true, ASP.NET compresses (and decompresses) serialized session state by using the .NET Framework GZipStream class. The following example shows how to set this attribute.

<sessionState
    mode="SqlServer"
    sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"
    allowCustomSqlDatabase="true"
    compressionEnabled="true"
/>

Two properties have been added to the Page class: MetaKeywords and MetaDescription. These two properties represent corresponding meta tags in the HTML rendered for a page, as shown in the following example:

<head id="Head1" runat="server">
  <title>Untitled Page</title>
  <meta name="keywords" content="keyword1, keyword2' />
  <meta name="description" content="Description of my page" />
</head>

These two properties work like the Title property does, and they can be set in the @ Page directive. For more information, see Page..::.MetaKeywords and Page..::.MetaDescription.

A new property has been added to the Control class: ViewStateMode. You can use this property to disable view state for all controls on a page except those for which you explicitly enable view state.

View state data is included in a page's HTML and increases the amount of time it takes to send a page to the client and post it back. Storing more view state than is necessary can cause significant decrease in performance. In earlier versions of ASP.NET, you could reduce the impact of view state on a page's performance by disabling view state for specific controls. But sometimes it is easier to enable view state for a few controls that need it instead of disabling it for many that do not need it.

For more information, see Control..::.ViewStateMode.

ASP.NET includes a feature that is named browser capabilities that lets you determine the capabilities of the browser that a user is using. Browser capabilities are represented by the HttpBrowserCapabilities object which is stored in the HttpRequest..::.Browser property. Information about a particular browser's capabilities is defined by a browser definition file. In ASP.NET 4, these browser definition files have been updated to contain information about recently introduced browsers and devices such as Google Chrome, Research in Motion BlackBerry smart phones, and Apple iPhone. Existing browser definition files have also been updated. For more information, see How to: Upgrade an ASP.NET Web Application to ASP.NET 4 and ASP.NET Web Server Controls and Browser Capabilities.

The browser definition files that are included with ASP.NET 4 are shown in the following list:

•blackberry.browser

•chrome.browser

•Default.browser

•firefox.browser

•gateway.browser

•generic.browser

•ie.browser

•iemobile.browser

•iphone.browser

•opera.browser

•safari.browser

ASP.NET 4 includes a new feature referred to as browser capabilities providers. As the name suggests, this lets you build a provider that in turn lets you write custom code to determine browser capabilities.

In ASP.NET version 3.5 Service Pack 1, you define browser capabilities in an XML file. This file resides in a machine-level folder or an application-level folder. Most developers do not need to customize these files, but for those who do, the provider approach can be easier than dealing with complex XML syntax. The provider approach makes it possible to simplify the process by implementing a common browser definition syntax, or a database that contains up-to-date browser definitions, or even a Web service for such a database.

For more information about the new browser capabilities provider, see the What's New for ASP.NET 4 White Paper.

ASP.NET 4 adds built-in support for routing with Web Forms. Routing is a feature that was introduced with ASP.NET 3.5 SP1 and lets you configure an application to use URLs that are meaningful to users and to search engines because they do not have to specify physical file names. This can make your site more user-friendly and your site content more discoverable by search engines.

For example, the URL for a page that displays product categories in your application might look like the following example:

http://website/products.aspx?categoryid=12

By using routing, you can use the following URL to render the same information:

http://website/products/software

The second URL lets the user know what to expect and can result in significantly improved rankings in search engine results.

the new features include the following:

• The PageRouteHandler class is a simple HTTP handler that you use when you define routes. You no longer have to write a custom route handler.

• The HttpRequest..::.RequestContext and Page..::.RouteData properties make it easier to access information that is passed in URL parameters.

  • The RouteUrl expression provides a simple way to create a routed URL in markup.

  • The RouteValue expression provides a simple way to extract URL parameter values in markup.

• The RouteParameter class makes it easier to pass URL parameter values to a query for a data source control (similar to FormParameter).

• You no longer have to change the Web.config file to enable routing.

For more information about routing, see the following topics:

• ASP.NET Routing

• Walkthrough: Using ASP.NET Routing in a Web Forms Application

• How to: Define Routes for Web Forms Applications

• How to: Construct URLs from Routes

• How to: Access URL Parameters in a Routed Page

The new ClientIDMode property makes it easier to write client script that references HTML elements rendered for server controls. Increasing use of Microsoft Ajax makes the need to do this more common. For example, you may have a data control that renders a long list of products with prices and you want to use client script to make a Web service call and update individual prices in the list as they change without refreshing the entire page.

Typically you get a reference to an HTML element in client script by using the document.GetElementById method. You pass to this method the value of the id attribute of the HTML element you want to reference. In the case of elements that are rendered for ASP.NET server controls earlier versions of ASP.NET could make this difficult or impossible. You were not always able to predict what id values ASP.NET would generate, or ASP.NET could generate very long id values. The problem was especially difficult for data controls that would generate multiple rows for a single instance of the control in your markup.

ASP.NET 4 adds two new algorithms for generating id attributes. These algorithms can generate id attributes that are easier to work with in client script because they are more predictable and that are easier to work with because they are simpler. For more information about how to use the new algorithms, see the following topics:

• ASP.NET Web Server Control Identification

• Walkthrough: Making Data-Bound Controls Easier to Access from JavaScript

• Walkthrough: Making Controls Located in Web User Controls Easier to Access from JavaScript

• How to: Access Controls from JavaScript by ID

The GridView and ListView controls enable users to select a row. In previous versions of ASP.NET, row selection was based on the row index on the page. For example, if you select the third item on page 1 and then move to page 2, the third item on page 2 is selected. In most cases, is more desirable not to select any rows on page 2. ASP.NET 4 supports Persisted Selection, a new feature that was initially supported only in Dynamic Data projects in the .NET Framework 3.5 SP1. When this feature is enabled, the selected item is based on the row data key. This means that if you select the third row on page 1 and move to page 2, nothing is selected on page 2. When you move back to page 1, the third row is still selected. This is a much more natural behavior than the behavior in earlier versions of ASP.NET. Persisted selection is now supported for the GridView and ListView controls in all projects. You can enable this feature in the GridView control, for example, by setting the EnablePersistedSelection property, as shown in the following example:

<asp:GridView id="GridView2" runat="server" PersistedSelection="true">
</asp:GridView>

The FormView control is enhanced to make it easier to style the content of the control with CSS. In previous versions of ASP.NET, the FormView control rendered it contents using an item template. This made styling more difficult in the markup because unexpected table row and table cell tags were rendered by the control. The FormView control supports RenderOuterTable, a property in ASP.NET 4. When this property is set to false, as show in the following example, the table tags are not rendered. This makes it easier to apply CSS style to the contents of the control.

<asp:FormView ID="FormView1" runat="server" RenderTable="false">

For more information, see FormView Web Server Control Overview.

The ListView control, which was introduced in ASP.NET 3.5, has all the functionality of the GridView control while giving you complete control over the output. This control has been made easier to use in ASP.NET 4. The earlier version of the control required that you specify a layout template that contained a server control with a known ID. The following markup shows a typical example of how to use the ListView control in ASP.NET 3.5.

<asp:ListView ID="ListView1" runat="server">
    <LayoutTemplate>
        <asp:PlaceHolder ID="ItemPlaceHolder" runat="server"></asp:PlaceHolder>
    </LayoutTemplate>
    <ItemTemplate>
        <% Eval("LastName")%>
    </ItemTemplate>
</asp:ListView>

In ASP.NET 4, the ListView control does not require a layout template. The markup shown in the previous example can be replaced with the following markup:

<asp:ListView ID="ListView1" runat="server">
    <ItemTemplate>
        <% Eval("LastName")%>
    </ItemTemplate>
</asp:ListView>

For more information, see ListView Web Server Control Overview.

A very common task for developers who create data-driven Web pages is to filter data. This traditionally has been performed by building Where clauses in data source controls. This approach can be complicated, and in some cases the Where syntax does not let you take advantage of the full functionality of the underlying database.

To make filtering easier, a new QueryExtender control has been added in ASP.NET 4. This control can be added to EntityDataSource or LinqDataSource controls in order to filter the data returned by these controls. Because the QueryExtender control relies on LINQ, but you do not to need to know how to write LINQ queries to use the query extender.

The QueryExtender control supports a variety of filter options. The following lists QueryExtender filter options.

For more information, see QueryExtenderQueryExtender Web Server Control Overview.

Earlier versions of ASP.NET controls sometimes render markup that does not conform to HTML, XHTML, or accessibility standards. ASP.NET 4 eliminates most of these exceptions.

For details about how the HTML that is rendered by each control meets accessibility standards, see ASP.NET Controls and Accessibility.

CSS for Controls that Can be Disabled

CSS for Validation Controls

CSS for the Hidden Fields Div Element

CSS for the Table, Image, and ImageButton Controls

CSS for the UpdatePanel and UpdateProgress Controls

Eliminating Unnecessary Outer Tables

Layout Templates for Wizard Controls

New HTML Formatting Options for the CheckBoxList and RadioButtonList Controls

Header and Footer Elements for the Table Control

CSS and ARIA Support for the Menu Control

Valid XHTML for the HtmlForm Control

Maintaining Backward Compatibility in Control Rendering

You can use Dynamic Data features in existing ASP.NET Web applications that do not use scaffolding by enabling Dynamic Data for individual data-bound controls. Dynamic Data provides the presentation and data layer support for rendering these controls. When you enable Dynamic Data for data-bound controls, you get the following benefits:

• Setting default values for data fields. Dynamic Data enables you to provide default values at run time for fields in a data control.

• Interacting with the database without creating and registering a data model.

• Automatically validating the data that is entered by the user without writing any code.

For more information, see Walkthrough: Enabling Dynamic Data in ASP.NET Data-Bound Controls.

ASP.NET 4 introduces two new built-in field templates, EmailAddress.ascx and Url.ascx. These templates are used for fields that are marked as EmailAddress or Url using the DataTypeAttribute attribute. For EmailAddress objects, the field is displayed as a hyperlink that is created by using the mailto: protocol. When users click the link, it opens the user's e-mail client and creates a skeleton message. Objects typed as Url are displayed as ordinary hyperlinks.

The following example shows how to mark fields.

[DataType(DataType.EmailAddress)]
public object HomeEmail { get; set; }

[DataType(DataType.Url)]
public object Website { get; set; }

Dynamic Data uses the new routing feature that was added in the .NET Framework 3.5 SP1 to control the URLs that users see when they access the Web site. The new DynamicHyperLink control makes it easy to build links to pages in a Dynamic Data site.

For information, see How to: Create Table Action Links in Dynamic Data

Both the ADO.NET Entity Framework and LINQ to SQL support inheritance in their data models. An example of this might be a database that has an InsurancePolicy table. It might also contain CarPolicy and HousePolicy tables that have the same fields as InsurancePolicy and then add more fields. Dynamic Data has been modified to understand inherited objects in the data model and to support scaffolding for the inherited tables.

For more information, see Walkthrough: Mapping Table-per-Hierarchy Inheritance in Dynamic Data.

The Entity Framework has rich support for many-to-many relationships between tables, which is implemented by exposing the relationship as a collection on an Entity object. New field templates (ManyToMany.ascx and ManyToMany_Edit.ascx) have been added to provide support for displaying and editing data that is involved in many-to-many relationships.

For more information, see Working with Many-to-Many Data Relationships in Dynamic Data.

The DisplayAttribute has been added to give you additional control over how fields are displayed. The DisplayNameAttribute attribute in earlier versions of Dynamic Data enabled you to change the name that is used as a caption for a field. The new DisplayAttribute class lets you specify more options for displaying a field, such as the order in which a field is displayed and whether a field will be used as a filter. The attribute also provides independent control of the name that is used for the labels in a GridView control, the name that is used in a DetailsView control, the help text for the field, and the watermark used for the field (if the field accepts text input).

The EnumDataTypeAttribute class has been added to let you map fields to enumerations. When you apply this attribute to a field, you specify an enumeration type. Dynamic Data uses the new Enumeration.ascx field template to create UI for displaying and editing enumeration values. The template maps the values from the database to the names in the enumeration.

Dynamic Data 1.0 had built-in filters for Boolean columns and foreign-key columns. The filters did not let you specify the order in which they were displayed. The new DisplayAttribute attribute addresses this by giving you control over whether a column appears as a filter and in what order it will be displayed.

An additional enhancement is that filtering support has been rewritten to use the new QueryExtender feature of Web Forms. This lets you create filters without requiring knowledge of the data source control that the filters will be used with. Along with these extensions, filters have also been turned into template controls, which lets you add new ones. Finally, the DisplayAttribute class mentioned earlier allows the default filter to be overridden, in the same way that UIHint allows the default field template for a column to be overridden.

For more information, see

Walkthrough: Filtering Rows in Tables That Have a Parent-Child Relationship

QueryableFilterRepeater

The Visual Web Developer designer in Visual Studio 2010 has been updated to improve CSS 2.1 standards compliance. The designer better preserves HTML source code and is more robust than in previous versions of Visual Studio.

In the HTML editor, IntelliSense auto-completes tag names. The IntelliSense Snippets feature auto-completes whole tags and more. In Visual Studio 2010, IntelliSense snippets are supported for JScript, alongside C# and Visual Basic, which were supported in earlier versions of Visual Studio.

Visual Studio 2010 includes over 200 snippets that help you auto-complete common ASP.NET and HTML tags, including required attributes (such as runat="server") and common attributes specific to a tag (such as ID, DataSourceID, ControlToValidate, and Text).

You can download additional snippets, or you can write your own snippets that encapsulate the blocks of markup that you or your team use for common tasks. For more information on HTML snippets, see Walkthrough: Using HTML Snippets.

In Visual 2010, JScript IntelliSense has been redesigned to provide an even richer editing experience. IntelliSense now recognizes objects that have been dynamically generated by methods such as registerNamespace and by similar techniques used by other JavaScript frameworks. Performance has been improved to analyze large libraries of script and to display IntelliSense with little or no processing delay. Compatibility has been significantly increased to support almost all third-party libraries and to support diverse coding styles. Documentation comments are now parsed as you type and are immediately leveraged by IntelliSense.