Wednesday, July 22, 2009

Enhancements in ASP.Net 4.0 ( Features )

1. AutoLoading: Asp.Net 4.0 helps for auto loading of required code in to the web application before serving the first request, by making changes in the configuration of applicationHost.config file

Some Web applications need to load large amounts of data or 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.

A new scalability feature named auto-start that directly addresses this scenario is available when ASP.NET 4.0 runs on IIS 7.5 on Windows Server 2008 R2. The auto-start feature provides a controlled approach for starting up an application pool, initializing an ASP.NET application, and then accepting HTTP requests.

To use the auto-start feature, 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="/"

-preloadEnabled="true"

-preloadProvider="PrewarmMyCache" >

<-/application>

<-/site>

<-/sites>

<-!-- Additional content -->

<-preloadProviders>

<-add name="PrewarmMyCache"

-type="MyNamespace.CustomInitialization, MyLibrary" />

<-/preloadProviders>

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 need to be automatically started. For each application that is marked for auto-start, IIS7.5 sends a request to ASP.NET 4.0 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 preloadProvider attribute (as shown in the previous example) and calls into its public entry point.

You create a managed auto-start type with the necessary 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 the method returns, the ASP.NET application is ready to process requests.

With the addition of auto-start to IIS 7.5 and ASP.NET 4.0, you now have a well-defined approach for performing expensive application initialization prior to processing the first HTTP request. For example, you can use the new auto-start feature to initialize an application and then signal a load-balancer that the application was initialized and ready to accept HTTP traffic.

2. RedirectPermanent: Asp.net 4.0 eliminates the unnecessary round trip and HTTP 302 issues by introducing a new RedirectPermanent method that makes it easy to resolve HTTP 301 issue and stops unnecessary round trips made by the browser for temporary redirects, as the following example:

RedirectPermanent ("/path/redirectForm.aspx");

3. Setting Meta Tags with the Page.Keywords and Page.Description Properties :ASP.NET 4.0 Web Forms adds two properties Keywords and Description to the page class they will help web application to optimize from SEO point of view

4. CompressionEnabled: ASP.NET 4.0 adds a compression optioncompressionEnabled for out-of-process session-state providers. WhencompressionEnabled is set to true Asp.Net will compress the serialized session state before it is sent to remote storage, it uses System.IO.Compression.GZipStream class

<-sessionState

-mode="SqlServer"

- sqlConnectionString="data source=dbserver;Initial Catalog=aspnetstate"

-allowCustomSqlDatabase="true"

-compressionEnabled="true"

/>

5. Builtin-Routing: ASP.NET 4.0 is built-in support for using routing with Web Forms.

One of the features being added in ASP.NET 4.0 is built-in support for using routing with Web Forms. Routing lets you configure an application to accept request URLs that do not map to physical files. Instead, you can use routing to define URLs that are meaningful to users and that can help with search-engine optimization (SEO) for your application. For example, the URL for a page that displays product categories in an existing application might look like the following example:

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

By using routing, you can configure the application to accept the following URL to render the same information:

http://yourwebsite/products/softwares

6. ClientIdMode: Asp.Net 4.0 introduces a new property ClientIdMode with possible settings as: Legacy, Static, Predictable and Inherit. It will help you to reduce the length of the nested controls Client IDs

The new ClientIdMode property addresses a long-standing issue in ASP.NET, namely how controls create the the id attribute for elements that they render. Knowing the id attribute for rendered elements is important if your application includes client script that references these elements.

The id attribute for Web server controls is generated based on the ClientId property of the control. The algorithm up to now for generating the id attribute from the ClientId property has been to concatenate the naming container (if any) with the ID, and in the case of repeated controls (as in data controls), to add a prefix and a sequential number. While this has always guaranteed that the IDs of controls in the page are unique, the algorithm has resulted in control IDs that were not predictable, and were therefore difficult to reference in client script.

The new ClientIdMode property lets you specify more precisely how the client ID is generated for controls. You can set the ClientIdMode property for any control, including for the page. Possible settings are the following:

Legacy This is equivalent to the ClientID property behavior for earlier versions of ASP.NET. This is also the default if no ClientIdMode property is set in the current control’s hierarchy.

Static This lets you specify an ID to be used as-is, no matter what naming container the control is in. (This is sometimes referred to as the "you set it, you get it" option.) The Static option gives you the most control over the ID, but is the least safe, in that ASP.NET does not prevent you from generating duplicate or invalid IDs.

Predictable This option is primarily for use in data controls that use repeating templates. It uses ID attributes of the parent control's naming containers, but generated IDs do not have names that contain strings like "ctlxxx". Only a user-defined ID will be included in the resulting control ID. This setting works in conjunction with the RowClientIdSuffix property of the parent control to allow you to define values that create unique IDs for each instance of the control. A typical example is to use the primary key of a data record as part of the client ID.

Inherit This setting is the default behavior for controls; it specifies that a control's ID generation is the same as its parent. Explicitly setting ClientIdMode to Inherit specifies that this and any child controls whose ClientIdMode property is either not set or is set to Inherit will take the ClientIdMode value of any parent control. This includes the settings made for the page and in the configuration file.

7. ViewStateMode:

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. Developers can disable view state for individual controls in order to reduce page size, but must disable it explicitly for individual controls. In ASP.NET 4.0, Web server controls include a ViewStateMode property that gives you control-level granularity over whether view state is enabled. This lets you disable view state by default and then enable it only for the controls that require it in the page.

The ViewStateMode property has three possible values: Enabled, Disabled, and Inherit. The function of the property is probably clear from the names of these settings. Enabled enables view state for that control (or for any child controls that are set to Inherit or that have nothing set). Disabled disables view state, and Inherit specifies that the control gets its ViewStateMode setting from the parent control.

The following simple example shows how the ViewStateMode property works. The markup for the controls in the following page includes a ViewStateMode value:

<-form id="form1" runat="server">

<-script runat=”server”>

- protected override void OnLoad(EventArgs e) {

-if (!IsPostBack) {

-label1.Text = label2.Text = "[DynamicValue]";

-}

-base.OnLoad(e);

-}

<-/script>

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

-Disabled:

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

- Enabled:

<-/asp:PlaceHolder>

<-/asp:PlaceHolder>

<-hr />

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

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) 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:

Disabled: [DynamicValue]

Enabled: [DynamicValue]

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

Disabled: [DeclaredValue]

Enabled: [DynamicValue]

As you probably expect, label1(whose ViewStateMode value is set to Disabled) has not preserved the value that it was set to in code. However, label2 (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:

The Page class is just another control; it acts as the parent control for all the other controls in the page. This means that no control will save view state unless you set ViewStateMode to Enabled for that control or a control further up its control hierarchy, which includes the page. 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.

8. EmailAddress.ascx and Url.ascx templates: Asp.Net 4.0 introduces two new templates EmailAddress.ascx and Url.ascx.you can use these templates for EmailAddress or Url fields. For EmailAddress objects, the field is displayed as a hyperlink that is created by using the mailto: protocol which will refer to user's e-mail client where as Url objects displayed as normal displayed as a hyperlink referring to defined targets.

9. PersistedSelection: Asp.Net 4.0 introduces a new property PersistedSelection for data bound controls such as Gridview and Listview.It will persist your selected item in a Gridview or Listview page, even when you move from one page to another.

10. Removes Layout Template from ListView: In Asp.Net 4.0 it no needs to place a LayoutTemplate for ListView control or to set ItemPlaceholderIDcontrol ID

he 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.0. 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.

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

11. RenderTable: A new RenderTable property is now available that lets you specify whether the FormView control renders using a table. If the above property is seted to false it will display only the content in the item template without being rendering the FormView control in a table.

The FormView control is designed to give you full control over the rendered markup. However, consider the following example:

<-asp:FormView ID="FormView1" runat="server">

<-ItemTemplate>

- Content!

<-/ItemTemplate>

<-/asp:FormView>

This markup renders the following output to the page; notice that the FormView control renders an HTML table:

<-table cellspacing="0" border="0" id="FormView1" style="border-collapse:collapse;">

<-tr>

<-td colspan="2">

-Content!

<-/td>

<-/tr>

<-/table>

A new RenderTable property is now available that lets you specify whether the FormView control renders using a table. The following example shows how to set the property.

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

The previous example renders the following output, without the table, tr, and td elements:

Content!

This enhancement can make it easier to style the content of the control with CSS, because no unexpected tags are rendered by the control.

12. Changes to Browser Capabilities

ASP.NET determines the capabilities of the browser that a user is using to browse your site by using a feature called browser capabilities. In ASP.NET version 3.5 Service Pack 1, you can define the capabilities that a browser has in the following ways:

At the machine level, you create or update a .browser XML file in the following folder:

\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\Browsers

After you define the browser capability, you run the following command from the Visual Studio Command Prompt in order to rebuild the browser capabilities assembly and add it to the GAC:

aspnet_regbrowsers.exe –I c

For an individual application, you create a .browser file in the application’s App_Browsers folder. These approaches require you to change XML files, and for machine-level changes, you must restart the application after you run the aspnet_regbrowsers.exe process.

ASP.NET 4.0 includes a feature referred to as browser capabilities providers. As the name suggests, this lets you build a provider that in turn lets you use your own code to determine browser capabilities.

12. Filtering Data with the QueryExtender Control : Asp.Net 4.0 introduces a new control QueryExtender. This control can be added to EntityDataSource or LinqDataSource controls in order to filter the data returned by these controls. It will avoid the use of where clause in the data source controls which was a complicated process in earlier versions of .net framework data bound controls

The QueryExtender control supports a variety of filter options. The following sections describe these options and provide examples of how to use them.

Search :

For the search option, the QueryExtender control uses provided text to find records in specified fields. In the following example, the control uses the text that is entered in the TextBoxSearch control and searches for its contents in the ProductNameand Supplier.CompanyName columns in the data returned from the LinqDataSource control.

<-asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products">

<-/asp:LinqDataSource>

<-asp:QueryExtender TargetControlID="dataSource" runat="server">

<-asp:SearchExpression DataFields="ProductName, Supplier.CompanyName"

-SearchType="StartsWith">

<-asp:ControlParameter ControlID="TextBoxSearch" />

<-/asp:SearchExpression>

<-/asp:QueryExtender>

Range :

The range option is similar to the search option, but specifies a pair of values to define the range. In the following example, the QueryExtender control searches the UnitPrice column in the data returned from the LinqDataSource control. The range is read from the TextBoxFrom and TextBoxTo controls on the page.

<-asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products">

<-/asp:LinqDataSource>

<-asp:QueryExtender TargetControlID="dataSource" runat="server">

<-asp:RangeExpression DataField="UnitPrice" MinType="Inclusive"

-MaxType="Inclusive">

<-asp:ControlParameter ControlID="TextBoxFrom" />

<-asp:ControlParameter ControlID="TexBoxTo" />

<-/asp:RangeExpression>

<-/asp:QueryExtender>

PropertyExpression :

The property expression option lets you define a comparison to a property value. If the expression evaluates to true, the data that is being examined is returned. In the following example, the QueryExtender control filters data by comparing the data in the Discontinued column to the value from the CheckBoxDiscontinued control on the page.

<-asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products">

<-/asp:LinqDataSource>

<-asp:QueryExtender TargetControlID="dataSource" runat="server">

<-asp:PropertyExpression>

<-asp:ControlParameter ControlID="CheckBoxDiscontinued" Name="Discontinued" />

<-/asp:PropertyExpression>

<-/asp:QueryExtender>

CustomExpression :

Finally, you canspecify a custom expression to use with the QueryExtender control. This option lets you call a function in the page that defines custom filter logic. The following example shows how to declaratively specify a custom expression in the QueryExtender control.

<-asp:LinqDataSource ID="dataSource" runat="server"> TableName="Products">

<-/asp:LinqDataSource>

<-asp:QueryExtender TargetControlID="dataSource" runat="server">

<-asp:CustomExpression OnQuerying="FilterProducts" />

<-/asp:QueryExtender>

The following example shows the custom function that is invoked by the QueryExtender control. In this case, instead of using a database query that includes a Where clause, the code uses a LINQ query to filter the data.

protected void FilterProducts(object sender, CustomExpressionEventArgs e)

{

e.Query = from p in e.Query.Cast()

where p.UnitPrice >= 10

select p;

}

These examples show only one expression being used in the QueryExtender control at a time. However, you can include multiple expressions inside the QueryExtender control.

13. Many To Many RelationShips : Supports Entity framework with the help of newly introduced ManyToMany.ascx and ManyToMany_Edit.ascx field templates which provides support for provide support for displaying and editing data that is involved in many-to-many relationships.

14. New Attributes to Control Display and Support Enumerations

The DisplayAttribute has been added to give you additional control over how fields are displayed. The DisplayName attribute in earlier versions of Dynamic Data allowed 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 used for the labels in a GridView control, the name 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.

** Please Make a Note as the Blogger wont allow Some keywords so I included the '-' infornt for such codes,keywords in the examples I have used.. Hope you understands this Change .. This Just make you understand the features. any suggestions will be appriciated.. :)