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
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
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.
<-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" />