Several new features are part of ASP.NET 4.0. Broadly, they can be categorized into features promoting

1. New Functionality (including several new controls)
2. Reusability Enhancements (including Dynamic Data)
3. Performance  Enhancements (possibly the largest chunk of improvements)
4. Backwards Compatibility – ensuring that new features such as Dynamic Data etc. work for any asp.net application – including versions earlier than 4.0
5. IIS 7.0 and ASP.NET 4.0 Integration (Tighter integration leading to better control and better performance from the HTTP request pipeline)

New Functionality in ASP.NET 4.0

New Controls

ASP.NET Chart Control

The ASP.NET Chart control expands the data-visualization offerings in the .NET Framework. Using the Chart control, you can create ASP.NET pages that have intuitive and visually compelling charts for complex statistical or financial analysis.

The ASP.NET Chart control was introduced as an add-on to the .NET Framework version 3.5 SP1 release and is part of the .NET Framework 4 release.
The control includes the following features: 35 distinct chart types.

An unlimited number of chart areas, titles, legends, and annotations. A wide variety of appearance settings for all chart elements. 3-D support for most chart types. Smart data labels that can automatically fit around data points. Strip lines, scale breaks, and logarithmic scaling.

More than 50 financial and statistical formulas for data analysis and transformation. Simple binding and manipulation of chart data. Support for common data formats such as dates, times, and currency. Support for interactivity and event-driven customization, including client click events using Ajax. State management. Binary streaming.

Adding the Chart Control to an ASP.NET Page
The following example shows how to add a Chart control to an ASP.NET page by using markup. In the example, the Chart control produces a column chart for static data points.

   1:  <asp:Chart ID="Chart1" runat="server">

   2:  <Series>

   3:  <asp:Series Name="Series1" ChartType="Column">

   4:  <Points>

   5:  <asp:DataPoint AxisLabel="Product A" YValues="345"/>

   6:  <asp:DataPoint AxisLabel="Product B" YValues="456"/>

   7:  <asp:DataPoint AxisLabel="Product C" YValues="125"/>

   8:  <asp:DataPoint AxisLabel="Product D" YValues="957"/>

   9:  </Points>

  10:  </asp:Series>

  11:  </Series>

  12:  <ChartAreas>

  13:  <asp:ChartArea Name="ChartArea1">

  14:  <AxisY IsLogarithmic="True" />

  15:  </asp:ChartArea>

  16:  </ChartAreas>

  17:  <Legends>

  18:  <asp:Legend Name="Legend1" Title="Product Sales" />

  19:  </Legends>

  20:  </asp:Chart>

Using 3-D Charts

The Chart control contains a ChartAreas collection, which can contain ChartArea objects that define characteristics of chart areas. For example, to use
3-D for a chart area, use the Area3DStyle property as in the following example:

More about ASP.Net Chart Controls can be found here.
ListView Control Enhancements
The ListView 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.

A bevy of new controls that provide unprecedented capabilities such as 3D charting, advanced ListView and RadioButtonGroup capabilities as well as a wizarding control (CreateUserWizard) that lets you specify exactly how your output HTML will be rendered – can significantly improve your next web application’s UI layout and design.

Reusability Improvements in ASP.NET 4.0

Dynamic Data Templates – Minimizing your C.R.U.D. effort

CRUD (Create, Read, Update, Delete) operations lie at the heart of every dynamic web application – whether it is built using PHP, ASP.NET or any other web application platform. One of the drawbacks to CRUD is that each page (WebForm) that requires any of these operations needs to have its own set of CRUD operations. Hence – an Order Display page has its own small subset of CRUD (Read) whereas an Order Update page has an UPDATE (and possibly DELETE) operation in the code-behind.  This leads to a lot of code.

What if you did not have to write any of the CRUD code? What if all you needed to do was define your business objects (e.g. Order and OrderDetail) – and have ASP.NET take care of creating, reading, updating and deleting instances of these – depending on the user’s action?

That is exacly what Dynamic Data Templates let you do.

Dynamic Data was introduced in the .NET Framework 3.5 SP1 release in mid-2008.

Providing many enhancements for creating data-driven applications, Dynamic Data includes the following:

1. RAD experience for quickly building a data-driven Web site.
2. Automatic validation that is based on constraints defined in the data model.
3. Field Templates – for easy modification of generated markup for fields in the GridView and DetailsView controls.

For ASP.NET 4, Dynamic Data has been enhanced to give developers even more power for quickly building data-driven Web sites.

Enabling Dynamic Data for Existing Projects
Dynamic Data features that shipped in the .NET Framework 3.5 SP1 brought new features such as the following:

1. Field templates – These provide data-type-based templates for data-bound controls. Field templates provide a simpler way to customize the look of   data controls than using template fields for each field. \
2. Validation – Dynamic Data lets you use attributes on data classes to specify validation for common scenarios like required fields, range checking, type checking, pattern matching using regular expressions, and custom validation. Validation is enforced by the data controls.
3. However, these features had the following requirements:
     * The data-access layer had to be based on Entity Framework or LINQ to SQL.
     * The only data source controls supported for these features were the EntityDataSource or LinqDataSource controls.
     * The features required a Web project that had been created using the Dynamic Data or Dynamic Data Entities templates in order to have all the files    that were required to support the feature.
   
   A major goal of Dynamic Data support in ASP.NET 4 is to enable the new functionality of Dynamic Data for any ASP.NET application. The following example shows markup for controls that can take advantage of Dynamic Data functionality in an existing page.

Code Snippet

1. <asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="True"  DataKeyNames="ProductID" DataSourceID="LinqDataSource1">   
2.        </asp:GridView>   
3.        <asp:LinqDataSource ID="LinqDataSource1" runat="server" ContextTypeName="DataClassesDataContext" EnableDelete="True" EnableInsert="True" EnableUpdate="True" TableName="Products">    
4.        </asp:LinqDataSource>

Dynamic Data Templates Summary

Dynamic data templates are a great way to reduce your C.R.U.D. effort. They can be used on non-4.0 controls as well as the newer 4.0 controls. For other strategies besides Dynamic Data Templates for minimizing your CRUD effort, see this blog on the Generic Data Access Layer.

Detailed information on Dynamic Data can be found on MSDN - Dynamic Data documentation. 

Performance enhancements in ASP.NET 4.0

Probably the most important set of enhancements, these can be broadly categorized as ‘Client Side’ performance enhancements and ‘Server Side’ performance enhancements.

Client Side Enhancements

Among the many client side improvements made in ASP.NET 4.0, perhaps the AJAX functionality is among the most exciting. AJAX is truly going into realms that no client side technology has stepped into before, including:

• Accessing an ADO.NET Data Service from AJAX
• Binding to DataView Control for displaying dynamic data using AJAX
• Support for Live Data Binding (Observable Collections) in AJAX
• Microsoft’s Content Delivery Network to improve performance of your AJAX applications

These are discussed in detail below.

Server Side Enhancements

Some of the most important changes in ASP.NET 4.0 are all server side performance related. These include:

• Caching Enhancements
• Performance Monitoring Improvements - including 'per-application' memory profiling
• Shrinking web.config
• Shrinking session state
• View state on individual controls

addition to AJAX improvements, some other inclusions that simplify client side development include the jQuery open source library – bundled up with both – new WebForm projects as well as new ASP.NET MVC projects. Other client side enhancements include improved CSS rendering options and inline HTML coding. This post will discuss all these in some detail.

Client Side Peformance Enhancements

ASP.Net Ajax 4.0

The AJAX functionality in ASP.NET 4.0 enables new client data scenarios for page and component developers that allow JSON data from the server to be rendered as HTML in a highly manageable and efficient way." ASP.NET Ajax 4.0 has in it many interesting features. Before we begin looking at those features, let’s first know what the compatible browsers are. Microsoft ASP.NET Ajax 4.0 is supported on a wide variety of web browsers. These include:

• Microsoft Internet Explorer 6, 7 and 8 RC1
• Mozilla Firefox 2 and 3
• Apple Safari 3
• Opera 9.6
  

  New Ajax Enhancements in ASP.NET 4.0

  AJAX 4.0 provides many flexible features - we will look at those features in this section. Here is a list of the enhancements made to the release of ASP.NET 4.0 for providing Ajax support:

  • Support for Live data binding
  • Support for Client-side template rendering
  • Support for declarative instantiation of client components
  • Support for using the Observer pattern on JavaScript objects and arrays
  • Support for invoking ADO.NET Data Services and Data Contexts
  • Support for the DataView control

Getting Started with ASP.NET Ajax 4.0

You can Ajax - enable a web page either by using the ScriptManager control or by using <script> tags. Here is an example of the markup code that illustrates how you can Ajax - enable a web page using the ScriptManager control.

   1:    <asp:ScriptManager ID="ScriptManager1" runat="server">

   2:      <Scripts>

   3:          <asp:ScriptReference Name="MicrosoftAjax.js" Path="~/scripts/MicrosoftAjax.js" />

   4:          <asp:ScriptReference ScriptMode="Inherit" Path="~/scripts/MicrosoftAjaxTemplates.js" />

   5:          <asp:ScriptReference ScriptMode="Inherit" Path="~/scripts/MicrosoftAjaxAdoNet.js" />

   6:      </Scripts>

   7:  </asp:ScriptManager>

   1:  <script type="text/javascript" src="../scripts/MicrosoftAjax.debug.js"></script>

   2:  <script type="text/javascript" src="../scripts/MicrosoftAjaxTemplates.debug.js"></script>

   3:  <script type="text/javascript" src="../scripts/MicrosoftAjaxAdoNet.debug.js"></script>

Support for Live Data Binding

Live data binding is a concept that allows you to ensure that data is bound at real time. In essence, this ensures that if there is any change in the data source; the change is reflected on the data bound controls. The support for live data binding is provided in ASP.NET Ajax 4.0 through the Observer pattern. The Sys.Observer interface provides support for live data binding in ASP.NET Ajax 4.0. Note that such data binding can be either one-way or two-way. In the former case, if the source of the data changes after the template has been rendered, the rendered data would not be updated automatically. Here is an example that illustrates how you can specify one-way data binding in your markup code:

<h3>{{ FirstName }}</h3>

However in the later case, if the source of data changes, or vice-versa, the changes are reflected automatically. Here is a code snippet that illustrates how you can implement two-way data binding:

<input type="text" value="{binding FirstName}"/>

Support for Data Contexts and ADO.NET Data Service

ASP.NET AJAX contains two data contexts in MicrosoftAjaxAdoNet.js. These are:

• Sys.Data.DataContext
• Sys.Data.AdoNetDataContext

Here is how you can use Sys.Data.AdoNetDataContext in your application:

   1:  var dataContext = new Sys.Data.AdoNetDataContext();

   2:  dataContext.set_serviceUri("EmployeeDataService.svc");

   3:  dataContext.initialize();

Refer to the code listing above. The set_serviceUri() method is used to connect to and work with either ADO.NET Data Service or WCF service.

Accessing an ADO.NET Data Service using ASP.NET Ajax 4.0

The following code snippet shows how you can use the DataContext class:

   1:  <script type="text/javascript">

   2:      var dataContext = new Sys.Data.DataContext();

   3:      dataContext.set_serviceUri("../EmployeeDataService.svc");

   4:      dataContext.initialize();

   5:  </script>

Note that you are using an ADO.NET data service; you should use the AdoNetDataContext class in lieu of the DataContext class, which is more generic. Actually, the AdoNetDataContext class extends the DataContext class. In essence, the AdoNetDataContext class provides features that are more specific to ADO.NET, i.e., identity management, change management, support for hierarchical data, and optimistic concurrency. The following code snippet illustrates how you can use Ajax to read employee records from an ADO.NET Data Service and display the name and addresses of each of the employees.

   1:  <body xmlns:sys="javascript:Sys"

   2:      xmlns:dataview="javascript:Sys.UI.DataView"

   3:      sys:activate="*">

   4:    <h1>This is a Sample Application</h1>

   5:    <div id="top">

   6:      <ul id="employeeListView" class="test sys-template"

   7:         sys:attach="dataview"

   8:         dataview:datasource="{{ new Sys.Data.AdoNetDataSource() }}"

   9:         dataview:serviceuri="../AdventureWorksAdo.svc"

  10:         dataview:query="Employee">

  11:        <li>

  12:          {{ Name }}

  13:          {{ Address }}

  14:        </li>

  15:      </ul>

  16:    </div>

  17:  </body>

   1:  <script type="text/javascript" src="script/MicrosoftAjax.js"></script>

   2:  <script type="text/javascript" src="script/MicrosoftAjaxTemplates.js"></script>

   3:  <script type="text/javascript" src="script/MicrosoftAjaxAdoNet.js"></script>

 

Support for the DataView control

The DataView control is used to bind to live data. In essence, you can use it to design and develop a dynamic data driven user interface. The DataView control is available in the System.UI.DataView namespace. The DataView control contains two important properties, namely, data and dataprovider. While the former is used to bind a JavaScript object, the later is used to connect to a WCF service. The following markup code shows how the DataView control can be used in ASP.NET Ajax 4.0:

   1:  <body xmlns:sys="javascript:Sys"

   2:      xmlns:dataview="javascript:Sys.UI.DataView"

   3:      sys:activate="*">

   4:      <ul sys:attach="dataview" class="sys-template"

   5:          dataview:data="{{ dataArray }}">

   6:          <li>

   7:              <h3>{{ EmployeeName }}</h3>

   8:              <div>{{ Address }}</div>

   9:          </li>

  10:      </ul>

  11:  </body>

Note that the data property of the DataView control is set to an array; the template is rendered once for each item in the array. Essentially, the DataView control supports binding to objects, arrays and services.

jQuery Included with Web Forms and MVC
The Visual Studio templates for both Web Forms and MVC include the open-source jQuery library. When you create a new website or project, a Scripts folder containing the following 3 files is created: jQuery-1.4.1.js – The human-readable, unminified version of the jQuery library. jQuery-14.1.min.js – The minified version of the jQuery library. jQuery-1.4.1-vsdoc.js – The Intellisense documentation file for the jQuery library.
Include the unminified version of jQuery while developing an application. Include the minified version of jQuery for production applications.
For example, the following Web Forms page illustrates how you can use jQuery to change the background color of ASP.NET TextBox controls to yellow when they have focus.

   1:  <%@ Page Language="C#" AutoEventWireup="true" CodeFile="ShowjQuery.aspx.cs" Inherits="ShowjQuery" %>

   1:  <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://cut.ms/WLY">

   2:  <html xmlns="http://cut.ms/WLZ">

   3:  <head runat="server">

   4:  <title>Show jQuery</title>

   5:  </head>

   6:  <body>

   7:  <form id="form1" runat="server">

   8:  <div>

   9:  <asp:TextBox ID="txtFirstName" runat="server" />

  10:  <br />

  11:  <asp:TextBox ID="txtLastName" runat="server" />

  12:  </div>

  13:  </form>

  14:  <script src="Scripts/jquery-1.4.1.js" type="text/javascript"></script>

  15:  <script type="text/javascript">

  16:  $("input").focus( function() { $(this).css("background-color", "yellow"); });

  17:  </script>

  18:  </body>

  19:  </html>

 

Content Delivery Network Support
The Microsoft Ajax Content Delivery Network (CDN) enables you to easily add ASP.NET Ajax and jQuery scripts to your Web applications. For example, you can start using the jQuery library simply by adding a <script> tag to your page that points to Ajax.microsoft.com like this:
<script src="http://cut.ms/WL1" type="text/javascript"></script>

By taking advantage of the Microsoft Ajax CDN, you can significantly improve the performance of your Ajax applications. The contents of the Microsoft Ajax CDN are cached on servers located around the world. In addition, the Microsoft Ajax CDN enables browsers to reuse cached JavaScript files for Web sites that are located in different domains.

The Microsoft Ajax Content Delivery Network supports SSL (HTTPS) in case you need to serve a web page using the Secure Sockets Layer.

To learn more about the Microsoft Ajax CDN, visit the following website: http://cut.ms/WL2

The ASP.NET ScriptManager supports the Microsoft Ajax CDN. Simply by setting one property, the EnableCdn property, you can retrieve all ASP.NET framework JavaScript files from the CDN:

<asp:ScriptManager ID="sm1" EnableCdn="true" runat="server" />

After you set the EnableCdn property to the value true, the ASP.NET framework will retrieve all ASP.NET framework JavaScript files from the CDN including all JavaScript files used for validation and the UpdatePanel. Setting this one property can have a dramatic impact on the performance of your web application.

You can set the CDN path for your own JavaScript files by using the WebResource attribute. The new CdnPath property specifies the path to the CDN used when you set the EnableCdn property to the value true:

   1:  [assembly: WebResource("Foo.js", "application/x-javascript", CdnPath = http://cut.ms/WL3)]

ClientID Generation for ASP.Net Controls

In order to access a server control from a client side script, a developer will require getting its client id. Predicting the ClientID of any control that is packed inside a parent like UserControls, MasterPage or any DataBound controls is a challenging task till day. For example, if we have 2 TextBox control inside a page that have an associated MasterPage then the ClientID will be similar to:

   1:  <input name="ctl00$ContentPlaceHolder1$TextBox2" type="text" id="ctl00_ContentPlaceHolder1_TextBox2" />

   2:  <input name="ctl00$ContentPlaceHolder1$TextBox3" type="text" id="ctl00_ContentPlaceHolder1_TextBox3" />

This is done to make the ID of the control unique in the page.
In earlier versions for asp.net, we can register a server side hidden control which can hold the ClientID of the server control to access it from client side. ASP.Net 4.0 addresses this difficulty by providing a new property called ClientIDMode for every controls and Page object. We can also set the property in configuration files.

This property will take the following 4 values:

1. Static : Setting this value will make the ClientID same as the ID. It will not concatenate ID of the parent naming containers.

 

   1:  <%@ Page Title="" Language="C#" MasterPageFile="~/MasterPage.master" ClientIDMode="Static"  AutoEventWireup="true" CodeFile="ClientIDs.aspx.cs" Inherits="Default2" %>

2. Predictable: This will be useful to predict the ClientID of child controls in data controls.

Setting this property will prevent the “ctlxxx” prefix in the ClientID.

This mode is mainly designed for databound controls though it can be defined on non-databound controls as well. Pre 4.0, the IDs that are generated for controls in a databound control was prefixed with autogenerated names such as ctrl0. Using the Predictable mode, along with the RowClientIdSuffix property, we can generate friendly IDs. Some databound controls like a Repeater does not support the RowClientIdSuffix property. If we set the mode to Predictable for a Repeater, the generated ID would look like ctlRepeater_Bob_1 where Bob is the value of the column. In controls such as ListView or GridView, the RowClientIdSuffix can be specified to be the column name (Ex: PersonID), the generated ID would look like ctlListView_1000_1 where 1000 is the PersonID.

This setting will make all the page controls to have ClientID same as ID. For example, if we have 2 Textbox controls, the output will be similar to:

   1:  <input name="ctl00$ContentPlaceHolder1$TextBox2" type="text" id="TextBox2" />

   2:  <input name="ctl00$ContentPlaceHolder1$TextBox3" type="text" id="TextBox3" /> 

3. Legacy: This value will make the ClientID generation same as earlier versions of ASP.Net

When the ClientIDMode is set to Legacy, the framework generates the Client ID of the control just like the way it did in the pre 4.0 days. The Client ID is a concatenated string of the parent containers and the control ID with an “_” (underscore) separator.

   1:  <asp:TextBox ID="txtTest" runat="server" ClientIDMode="Legacy"></asp:TextBox>

Rendered HTML:

   1:  <input name="WebUserControl1$txtTest" type="text" id="WebUserControl1_txtTest" />

4. Inherit This value will make the control to inherit the parent control’s setting. This is the default value for this property.

Essentially, this is the default mode. If we explicitly set the ClientIDMode to Inherit, the ClientIDMode of the parent control is used to determine the ID. If we set the User Control’s ClientIDMode to Static and the textbox’s ClientIDMode to Inherit, since the textbox is a child control, it uses the Static mode.
In Default.aspx

   1:  <uc1:WebUserControl ID="WebUserControl1" runat="server" ClientIDMode="Static" />

In WebUserControl.ascx

   1:  <asp:TextBox ID="txtTest" runat="server" ClientIDMode="Inherit"></asp:TextBox>

Rendered HTML

   1:  <input name="WebUserControl1$txtTest" type="text" id="txtTest" />

 

 

Different ways of setting the ClientIDMode

Control Level
ClientIDMode can be set at the control level as seen in the previous examples

Page Level
ClientIDMode can be set in the Page directive as shown in the code snippet

   1:  <%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" ClientIdMode="Static" %>

Application Level
ClientIDMode can be set in the Web.config file for applying the setting at the application level

   1:  <system.web>

   2:    <pages clientIdMode="Static"></pages>

   3:  </system.web>

Inline HTML Encoding

Html Encoded Code Expressions Some ASP.NET sites (especially with ASP.NET MVC) rely heavily on using :

   1:  <%= expression %>

syntax (often called “code nuggets”) to write some text to the response. When you use code expressions, it is easy to forget to HTML-encode the text, If the text comes from user input, it can leave pages open to an XSS (Cross Site Scripting) attack.

ASP.NET 4 introduces the following new syntax for code expressions:

   1:  <%: expression %>

This syntax uses HTML encoding by default when writing to the response. This new expression effectively translates to the following:

   1:  <%= HttpUtility.HtmlEncode(expression) %> 

For example,

   1:  <%: Request["UserInput"] %>

performs HTML encoding on the value of Request["UserInput"].

The goal of this feature is to make it possible to replace all instances of the old syntax with the new syntax so that you are not forced to decide at every step which one to use. However, there are cases in which the text being output is meant to be HTML or is already encoded, in which case this could lead to double encoding.
For those cases, ASP.NET 4 introduces a new interface, IHtmlString, along with a concrete implementation, HtmlString. Instances of these types let you indicate that the return value is already properly encoded (or otherwise examined) for displaying as HTML, and that therefore the value should not be HTML-encoded again. For example, the following should not be (and is not) HTML encoded:

   1:   <%: new HtmlString("<strong>HTML that is not encoded</strong>") %>

ASP.NET MVC 2 helper methods have been updated to work with this new syntax so that they are not double encoded, but only when you are running ASP.NET 4. This new syntax does not work when you run an application using ASP.NET 3.5 SP1.

Keep in mind that this does not guarantee protection from XSS attacks. For example, HTML that uses attribute values that are not in quotation marks can contain user input that is still susceptible. Note that the output of ASP.NET controls and ASP.NET MVC helpers always includes attribute values in quotation marks, which is the recommended approach.
Likewise, this syntax does not perform JavaScript encoding, such as when you create a JavaScript string based on user input.

ScriptManager Explicit Scripts

  In the past, if you used the ASP.NET ScriptManger then you were required to load the entire monolithic ASP.NET Ajax Library. By taking advantage of the new ScriptManager.AjaxFrameworkMode property, you can control exactly which components of the ASP.NET Ajax Library are loaded and load only the components of the ASP.NET Ajax Library that you need.

  The ScriptManager.AjaxFrameworkMode property can be set to the following values: Enabled -- Specifies that the ScriptManager control automatically includes the MicrosoftAjax.js script file, which is a combined script file of every core framework script (legacy behavior). Disabled -- Specifies that all Microsoft Ajax script features are disabled and that the ScriptManager control does not reference any scripts automatically. Explicit -- Specifies that you will explicitly include script references to individual framework core script file that your page requires, and that you will include references to the dependencies that each script file requires.

For example, if you set the AjaxFrameworkMode property to the value Explicit then you can specify the particular ASP.NET Ajax component scripts that you need:

   1:  <asp:ScriptManager ID="sm1" AjaxFrameworkMode="Explicit" runat="server">

   2:  <Scripts>

   3:  <asp:ScriptReference Name="MicrosoftAjaxCore.js" />

   4:  <asp:ScriptReference Name="MicrosoftAjaxComponentModel.js" />

   5:  <asp:ScriptReference Name="MicrosoftAjaxSerialization.js" />

   6:  <asp:ScriptReference Name="MicrosoftAjaxNetwork.js" />

   7:  </Scripts>

   8:  </asp:ScriptManager>

Setting Meta Tags with the Page.MetaKeywords and Page.MetaDescription Properties

ASP.NET 4 adds two properties to the Page class, MetaKeywords and MetaDescription. These two properties represent corresponding meta tags in your page, as shown in the following example:

   1:  <head id="Head1" runat="server">

   2:  <title>Untitled Page</title>

   3:  <meta name="keywords" content="These, are, my, keywords" />

   4:  <meta name="description" content="This is the description of my page" />

   5:  </head>

These two properties work the same way that the page’s Title property does. They follow these rules:
1. If there are no meta tags in the head element that match the property names (that is, name="keywords" for Page.MetaKeywords and name="description" for Page.MetaDescription, meaning that these properties have not been set), the meta tags will be added to the page when it is rendered.
2. If there are already meta tags with these names, these properties act as get and set methods for the contents of the existing tags.
You can set these properties at run time, which lets you get the content from a database or other source, and which lets you set the tags dynamically to describe what a particular page is for.
You can also set the Keywords and Description properties in the @ Page directive at the top of the Web Forms page markup, as in the following example:

   1:  <%@ Page Language="C#" AutoEventWireup="true"

   2: CodeFile="Default.aspx.cs"

   3:  Inherits="_Default"

   4:  Keywords="These, are, my, keywords" Description="This is a description" %>

This will override the meta tag contents (if any) already declared in the page. The contents of the description meta tag are used for improving search listing previews in Google. (For details, see Improve snippets with a meta description makeover on the Google Webmaster Central blog.) Google and Windows Live Search do not use the contents of the keywords for anything, but other search engines might. For more information, see Meta Keywords Advice on the Search Engine Guide Web site.
These new properties are a simple feature, but they save you from the requirement to add these manually or from writing your own code to create the meta tags.

CSS Improvements

The other major improvements in ASP.Net 4.0 are related to the way the HTML is rendered on the client browser. The rendered HTML can be made complaint with latest HTML standards by tweaking a configuration entry.

1. A new property called controlRenderingCompatibilityVersion is added to the Pages element of configuration files.

   1:  <pages controlRenderingCompatibilityVersion="3.5|4.0"/>

The value “3.5” indicates the controls are rendered in legacy ways. The value “4.0” indicates the control will be rendered with the latest improvements of 4.0 framework.

2. Till 3.5 framework, setting “Enabled=false” for any control will render disabled attributes in the HTML for the control. According to the latest HTML standard the disabled attribute should be set only for INPUT tags. ASP.Net 4.0 addresses this issue by rendering disabled attribute to only INPUT tags and a CSS class called “aspNetDisabled” to other controls to disable it when controlRenderingCompatibilityVersion property is set to “4.0”.

The example below shows the HTML rendered for a Label and TextBox control when controlRenderingCompatibilityVersion property is set to “4.0”.

   1:  <span id="Label1" class="aspNetDisabled">Label</span>

   2:  <input name="TextBox1" type="text" id="TextBox1" disabled="disabled" />

   3:   

3. From ASP.Net 2.0, the hidden fields generated for viewstate are packed inside a div tag for XHTML standard. This leads a small white space on the page. ASP.Net 4.0 now includes this div with a css class “aspNetHidden”. We can now define the class to prevent the white space by setting border to 0.

<div class="aspNetHidden">...</div>

4. Menu controls render markup that is semantically correct and compliant with accessibility guidelines.

5. Validation controls do not render inline styles.

Server Side Performance Enhancements in ASP.NET 4.0

Some of the most important changes in ASP.NET 4.0 are all related to the server side performance. These include:

• Caching Enhancements
• Performance Monitoring Improvements - including 'per-application' memory profiling
• Shrinking web.config
• Shrinking session state
• View state on individual controls

We shall discuss these one by one.

Caching Enhancements

Until now, any page output is stored in memory  in a private area of the ASP.NET cache. However, in the long run, the output cache puts additional pressure on the web server by consuming memory and generating frequent updates to the cache object. In ASP.NET 4.0, the output caching subsystem gives an opportunity to the developers to store page responses outside the ASP.NET worker process, by fully supporting the provider model. In ASP.NET 4.0, the Cache API enables you to use any of the following cache storages:

·         Disk-based output caches – store cache data in disk

·         Custom object caches – store cache data using custom cache providers

·         Distributed object caches – store cache data on a separate server

·         Cloud-based object caches – store cache data on a cloud database

You create a custom output-cache provider as a class that derives from the new System.Web.Caching.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:

   1:  <caching>

   2:  <outputCache defaultProvider="AspNetInternalProvider">

   3:  <providers>

   4:  <add name="DiskCache"

   5:  type="Test.OutputCacheEx.DiskOutputCacheProvider, DiskCacheProvider"/>

   6:  </providers>

   7:  </outputCache>

   8:  </caching>

By default in ASP.NET 4, all HTTP responses, rendered pages, and controls use the in-memory output cache, as shown 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 per control and per request. 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 control directive, as shown in the following example:

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

Specifying a different output cache provider for an HTTP request requires a little more work. Instead of declaratively specifying the provider, you override the new GetOuputCacheProviderName 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.

   1:  public override string GetOutputCacheProviderName(HttpContext context)

   2:  {

   3:  if (context.Request.Path.EndsWith("Advanced.aspx"))

   4:  return "DiskCache";

   5:  else

   6:  return base.GetOutputCacheProviderName(context);

   7:  }

With the addition of output-cache provider extensibility to ASP.NET 4, you can now pursue more aggressive and more intelligent output-caching strategies for your Web sites. For example, it is now possible to cache 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 can also use a new feature called Output Cache Substitution to cache the output of web pages that contain dynamic data. For example:

   1:  <asp:Substitution ID= "cacheSubstitution" runat="server"MethodName="Test" />

Shrinking Session State
ASP.NET provides two default options for storing session state across a Web farm:
a session-state provider that invokes an out-of-process session-state server, and a session-state provider that stores data in a Microsoft SQL Server database. Because both options involve storing state information outside a Web application's worker process, session state has to be serialized before it is sent to remote storage. Depending on how much information a developer saves in session state, the size of the serialized data can grow quite large.

ASP.NET 4 introduces a new compression option for both kinds of out-of-process session-state providers.
When the compressionEnabled configuration option shown in the following example is set to true, ASP.NET will compress (and decompress) serialized session state by using the .NET Framework System.IO.Compression.GZipStream class.

   1:  <sessionState

   2:  mode="SqlServer"

   3:  sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"

   4:  allowCustomSqlDatabase="true"

   5:  compressionEnabled="true"

   6:  />

With the simple addition of the new attribute to the Web.config file, applications with spare CPU cycles on Web servers can realize substantial reductions in the size of serialized session-state data.

Enabling View State for Individual Controls

By default, view state is enabled for the page, with the result that each control on the page potentially stores view state even if it is not required for the application. View state data is included in the markup that a page generates 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 performance degradation. In earlier versions of ASP.NET, developers could disable view state for individual controls in order to reduce page size, but had to do so explicitly for individual controls. In ASP.NET 4, Web server controls include a ViewStateMode property that lets you disable view state by default and then enable it only for the controls that require it in the page.
The ViewStateMode property takes an enumeration that has three values: Enabled, Disabled, and Inherit. Enabled enables view state for that control and for any child controls that are set to Inherit or that have nothing set. Disabled disables view state, and Inherit specifies that the control uses the ViewStateMode setting from the parent control.

The following example shows how the ViewStateMode property works. The markup and code for the controls in the following page includes values for the ViewStateMode property:

   1:  <form id="form1" runat="server">

   2:  <script runat="server">

   3:  protected override void OnLoad(EventArgs e) {

   4:  if (!IsPostBack) {

   5:  label1.Text = label2.Text = "[DynamicValue]";

   6:  }

   7:  base.OnLoad(e);

   8:  }

   9:  </script>

  10:  <asp:PlaceHolder ID="PlaceHolder1" runat="server" ViewStateMode="Disabled">

  11:  Disabled: <asp:Label ID="label1" runat="server" Text="[DeclaredValue]" /><br />

  12:  <asp:PlaceHolder ID="PlaceHolder2" runat="server" ViewStateMode="Enabled">

  13:  Enabled: <asp:Label ID="label2" runat="server" Text="[DeclaredValue]" />

  14:  </asp:PlaceHolder>

  15:  </asp:PlaceHolder>

  16:  <hr />

  17:  <asp:button ID="Button1" runat="server" Text="Postback" />

  18:  <%-- Further markup here --%>

As you can see, the code disables view state for the PlaceHolder1 control. The child label1 control inherits this property value (Inherit is the default value for ViewStateMode for controls.) and therefore saves no view state. In the PlaceHolder2 control, ViewStateMode is set to Enabled, so label2 inherits this property and saves view state. When the page is first loaded, the Text property of both Label controls is set to the string “*DynamicValue+”.

The effect of these settings is that when the page loads the first time, the following output is displayed in the browser:

   1:  Disabled: [DynamicValue]

   2:  Enabled: [DynamicValue]

After a postback, however, the following output is displayed:

   1:  Disabled: [DeclaredValue]

   2:  Enabled: [DynamicValue]

The label1 control (whose ViewStateMode value is set to Disabled) has not preserved the value that it was set to in code. However, the label2 control (whose ViewStateMode value is set to Enabled) has preserved its state.

You can also set ViewStateMode in the @ Page directive, as in the following example:

   1:  <%@ Page Language="C#" AutoEventWireup="true"

   2:  CodeBehind="Default.aspx.cs"

   3:  Inherits="WebApplication1._Default" ViewStateMode="Disabled" %>

The Page class is just another control; it acts as the parent control for all the other controls in the page. The default value of ViewStateMode is Enabled for instances of Page. Because controls default to Inherit, controls will inherit the Enabled property value unless you set ViewStateMode at page or control level.

The value of the ViewStateMode property determines if view state is maintained only if the EnableViewState property is set to true. If the EnableViewState property is set to false, view state will not be maintained even if ViewStateMode is set to Enabled.

A good use for this feature is with ContentPlaceHolder controls in master pages, where you can set ViewStateMode to Disabled for the master page and then enable it individually for ContentPlaceHolder controls that in turn contain controls that require view state.

Performance Monitoring for Individual Applications in a Single Worker Process

In order to increase the number of Web sites that can be hosted on a single server, many web-hosts run multiple ASP.NET applications in a single worker process. However, if multiple applications use a single shared worker process, it is difficult for server administrators to identify an individual application that is experiencing problems.

ASP.NET 4 leverages new resource-monitoring functionality introduced by the CLR. To enable this functionality, you can add the following XML configuration snippet to the aspnet.config configuration file.

   1:  <?xml version="1.0" encoding="UTF-8" ?>

   2:  <configuration>

   3:  <runtime>

   4:  <appDomainResourceMonitoring enabled="true"/>

   5:  </runtime>

   6:  </configuration>

NOTE: The aspnet.config file is in the directory where the .NET Framework is installed (as opposed to the folder containing the Web.config file).

When the appDomainResourceMonitoring feature has been enabled, two new performance counters are available in the "ASP.NET Applications" performance category: % Managed Processor Time and Managed Memory Used. Both of these performance counters use the new CLR application-domain resource management feature to track estimated CPU time and managed memory utilization of individual ASP.NET applications. As a result, with ASP.NET 4, administrators now have a more granular view into the resource consumption of individual applications running in a single worker process.

Shrinking web.config - Web.config File Refactoring

The Web.config file that contains the configuration for a Web application has grown considerably over the past few releases of the .NET Framework as new features have been added, such as Ajax, routing, and integration with IIS 7. This has made it harder to configure or start new Web applications without a tool like Visual Studio. In .the NET Framework 4, the major configuration elements have been moved to the machine.config file, and applications now inherit these settings. This allows the Web.config file in ASP.NET 4 applications either to be empty or to contain just the following lines, which specify for Visual Studio what version of the framework the application is targeting:

   1:  <?xml version="1.0"?>

   2:  <configuration>

   3:  <system.web>

   4:  <compilation targetFramework="4.0" />

   5:  </system.web>

   6:  </configuration>

Summary of Performance Enhancements

ASP.NET 4.0 Performance improvements include several client side as well as server side changes. On the client side, several AJAX and jQuery related improvements form part of the new functionality – and work together to reduce the load on the client as well as the server (by providing the client with powerful processing tools). On the server side ‘out of process’ caching, shrinking session state as well as granular control over the ViewState make the server side performance far better than prior versions of ASP.NET.  For monitoring and troubleshooting ASP.NET applications, a new ‘per-individual-application’ performance monitoring capability makes it easier to detect performance problems.

Backwards Compatibility

New features such as Dynamic Data are designed to work for any asp.net application – including versions earlier than 4.0. By providing default values of new properties to ‘inherit’, the ASP.NET team has ensured that previous versions of the runtime can use the new controls (the modified ListView and RadioButtonGroups) and features such as DynamicData without changing previous behavior

IIS 7.0 and ASP.NET Integration Enhancements

ASP.NET Enhancements on IIS 7

Better ASP.NET integration in IIS 7 enhances existing applications and also allows new applications to take advantage of ASP.NET features in new ways:

• ASP.NET services can be used for all content types. In the past, ASP.NET functionality such as Forms authentication, roles, URL authorization, and output caching were only available to ASP.NET content types like ASPX pages. Static files, ASP pages, and other content types could not benefit from these services.

In IIS 7, all ASP.NET services are provided uniformly to all content. For example, you can protect all of your Web content, including images and ASP pages, with your existing ASP.NET 2.0 access control solution built on ASP.NET Forms authentication, membership and login controls.

• Fully extend IIS with ASP.NET. Previous versions of IIS frequently required server extensibility to be developed by using the native ISAPI filter or extension extensibility mode, due to the runtime limitations of ASP.NET.

IIS 7 allows ASP.NET modules to plug in directly into the server pipeline, with the same runtime fidelity as modules developed with the native (C++) server API. ASP.NET modules can execute in all runtime stages of the request-processing pipeline, and can be executed in any order with respect to native modules. The ASP.NET API is also expanded to allow more control over request processing than was previously possible.

• Unified server runtime. Tighter ASP.NET integration also unifies many of the features between IIS 7 and ASP.NET.

IIS 7 provides a unified configuration for IIS and ASP.NET modules and handlers. Many other features, including custom errors and tracing, have been unified to allow better management and cohesive application design.

References:  Detailed ASP.Net Interaction with IIS 7.0 - ASP.NET Application Life Cycle Overview for IIS 7.0

In Conclusion

We have seen a lot of new features that are part of ASP.NET 4.0. Broadly speaking, these can be split up into ‘Performance Enhancing’, ‘Reusability Enhancing’ and ‘New Functionality’. The biggest set of enhancements is in the ‘Performance’ category – allowing unprecedented server side and client side scalability for your next ASP.NET 4.0 application.