Improving the Performance of ASP.Net Programming

Introduction

Today I am focusing on creating a secure and efficient application in ASP.NET. There are various ways to improve the performance of applications and enhance application efficiency. In this article I am suggesting various mistakes related to .NET classes and processes to be avoided.

There are very common mistakes made by people when creating web applications in ASP.NET. There are some recommendations provided here so that you should avoid these common mistakes.

Overview

In this section various topics are defined with which we can better understand the phenomena:

Standards Consent
- Control Adapters
- Control Style Property
- Page and Control Callbacks
- Browser Capability Detection
Security Recommendations
- Request Validation
- Cookieless Forms Authentication
- EnableViewStateMac
- App Settings
- UrlPathEncode
Performance
- Request Entity Body
- Response.Redirect and Response.End
- EnableViewState
- SqlMembershipProvider

Standards Consent

Control Adapters

Control Adapters were revealed in the .NET 2.0 Framework to display the layout of the code. Now in the current scenario you should stop using these and its the best to use the adaptive CSS and HTML methodology to accomplish. You should also convert the existing Control Adapters to CSS and HTML.

Control Style Property

You should stop using the Inline styles or say using the style property with the controls. You can use CSS Stylesheets instead of using the styles. It can accomplish the same consequence and more efficient using CSS Stylesheets.

Example: Instead of setting the ForeColor property in Style of Control to "Aqua", we can define the CSS Class for this. the following is the CSS class reresentation:

.RowStyle {
    color: aqua;
}

We can also apply the CSS Class dynamically. Consider the following code:

protected void DtaGridView_ItemDataBound(object sender, DataGridItemEventArgs e)
{
    e.Item.CssClass = "RowStyle";
}

In the code above, the CssClass is applied to the item of the DataGrid.

Page and Control Callbacks

We use the Page and Control Callbacks method for updating the page without refreshing the entire page in the previous version of ASP.NET but you can now fulfill the partial-page updates using the AJAX, UpdatePanel, MVC, Web API or SignalR. Now there are various ways to do partial-page update. You should stop using the callback methods because it can cause the issue with the friendly URLs and the routing. As the default, the callback method is disabled, but if you enabled it, you should disable this feature.

Browser Capability Detection

Now you should stop using the static browser detection and use Dynamic detection.

In the previous version of ASP.NET, the supported features for each browser were stored in the XML file. If the static browser detection is used for detecting the feature support, it is not the best approach. You should use the detection framework dynamically for detecting a browser supported features like Modernizr. It is used by attempting a method or property and review the browser to see that the browser is displaying the desirable result or not. In the current project templates the Modernizr is included as a default.

Modernizr in ASP.NET Project Templates

Security Recommendations

Request Validation

The Request Validation is the feature of ASP.NET to check each request and stop the request if an anticipated threat is found. You should not depend upon the request validation for securing the application from the cross-site scripting attacks. Instead, validate the input from users and encode the output.

You can use Regular Expressions in some cases but mostly you should use the .NET classes that describe if the input matches with allowed values to validate the user input.

In the following code, the Uri class is used to determine whether the URI provided by the user is valid or not:

static void Main(string[] args)
{
    var uri = "http://localhost:1234";
    var ValidUri = Uri.IsWellFormedUriString(uri, UriKind.Absolute);
}

We can encode the HTML with the use of <%: %> before rendering, as shown below:

<span><%: UserName %></span>

In the Razor syntax, you can HTML encode with the @, have a look:

<span>@UserName</span>

Cookieless Forms Authentication

It is not safe to pass the authentication information in the form of a query string, so you should use the cookies the authentication is include in the application. You can also use the requireSSL to store the essential information for a cookie.

The following markup specifies the Forms Authentication markup defined in the Web.Config file:

<authentication mode="Forms">
  <forms loginUrl="UserLogin.aspx" 
          cookieless="UseCookies" 
          requireSSL="true" 
          path="/Users/Administrator/">        
  </forms>
</authentication>

EnableViewStateMac

This should never be set to false. As a default it is set to true. If your application does not use the View State then you should not set EnableViewStateMac to false. By setting it to false, it will make the application vulnerable to cross-site scripting.

As I said, it is true as a default. You can also set it to true with the help of the following markup if it is false on any page in the application:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="MvcDropDownList.WebForm1" EnableViewStateMac="true" %>

App Settings

You do not disable the security settings in the <appSettings>. There are many values defined in this element that are required for the security updates. You should not disable these updates. If you disable these while deploying any update for the application, enable the settings after deploying the application.

UrlPathEncode

This method was added in the .NET Framework that is used to resolve a very specific browser compatibility problem. It is unable to protect the application from the cross-site scripting. You should not use it ever in the application. You can use UrlEncode instead of using this.

Note: You can refer to MSDN for the use of UrlEncode.

Performance

Request Entity Body

You should avoid reading Request.Form or Request.InputStream before executing the hander's event. In the previous version, you should read the handler's event by using the Request.Form or Request.InputStream. Now in the current scenario if we use an example of MVC then we find that the Controller in MVC is the handler and the execute event is when the corresponding action method runs. In the same context in Web Forms, The Page is the handler and the execute event is when the corresponding Page.Init method runs. If you read the request entity body before the execute event then you can conflict with the request processing.

Response.Redirect and Response.End

You should be aware of using the Response.Redirect and Response.End methods. When you use The Response.Redirect(String) method, it calls the Response.End method and mean while the process executes the current thread is immediately terminated. However, if you use the asynchronous process, calling the Response.Redirect does not terminate the current thread and the code execution continues for the request. You must resturn the task from the method for stopping the code execution in using the asynchronous process.

We should not use the Response.Redirect in the MVC project, instead return a RedirectResult.

EnableViewState

You should use the ViewStateMode instead of using the EnableViewState. When we set EnableViewState to false in the Page directive, the view state is disabled for all the controls in the page and cannot be enabled.

You can set the ViewStateMode to disabled for the page, and set it to enabled if any control needs it as shown in the following markup:

Page directive:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="MvcDropDownList.WebForm1" ViewStateMode="Disabled" %>

Control:

<asp:TextBox ID="TextBox1" ViewStateMode="Enabled" runat="server"></asp:TextBox>

SqlMembershipProvider

You should not use the SqlMembershipProvider and use the ASP.NET Universal Provider instead. You can find in the current project templates that the SqlMembershipProvider has been replaced by the Universal Providers. It is also available on the NuGet Package Gallery. You should also switch the existing applications in which the SqlMembership Provider is used to the Universal Provider. The Universal Provider works with all databases that are supported by the Entity Framework.

You can also get it from the Package Manager Console by entering the following command:

Install-Package Microsoft.AspNet.Providers

Summary

This article described the various features recommended for use in ASP.NET Web Applications and what's not to use in the application. Thanks for reading.