Archive

Posts Tagged ‘IIS’

ASP.Net 4.0 New Features

ViewStateMode – ViewState for Individual Controls
ASP.Net 4.0 allows view state in a page to be more controllable from page to its child controls level. That is, view state of a control can be enabled or disabled irrespective of its parent control’s view state. Even if view state of a page is disabled, controls of the page can have their own view state individually enabled or disabled or even inherited from the page’s view state mode property.
This property if utilized properly can certainly boost performance of a page.

For example, we can individually enable or disable user control’s view state in a page.

ViewStateMode

By default, ViewStateMode is enabled for a page object, while controls have inherit mode.

Page.MetaKeywords and Page.MetaDescription – SEO Optimization Feature
ASP.Net 4.0 has come up with these two properties that will help developers add meta tags for keywords and description in the aspx pages in easier fashion. Web Search Engines really need these two meta tags for search indexing of any pages. These two properties can be used in a page in various ways. Inside <head> tag or in the code behind or even at <%@Page%> directive level.

However, setting meta keywords or description in code behind will be more useful when we have to add keywords and descriptions dynamically from source like database.

MetaKeyWords is used to store few useful keywords that will briefly highlight important information of a page by tags. From SEO perspective, meta keywords should contain keywords separated by spaces.

MetaDescription is used to add page description in short that will help Search Engines to quickly describe about the page links in search pages.

Prior to ASP.Net 4.0, we have to add meta tags using HtmlMeta control (public class HtmlMeta : HtmlControl) adding into page header as:

protected void Page_Load(object sender, EventArgs e)
{
//
HtmlMeta metakey = new HtmlMeta();
metakey.Name = "keywords";
metakey.Content = "ASP.Net 2.0 3.5";
HtmlMeta metadesc = new HtmlMeta();
metadesc.Name = "description";
metadesc.Content = "ASP.Net 2.0 3.5 Page Description...";
//Add to page header
Page.Header.Controls.Add(metakey);
Page.Header.Controls.Add(metadesc);
}


In ASP.Net 4.0, we can add in many ways.

protected void Page_Load(object sender, EventArgs e)
{
//Adding Page meta tags information
this.Page.MetaKeywords = "ASP.Net 4.0 SEO Meta Tag";
this.Page.MetaDescription = "Serializing and Deserializing Thoughts..";
}

Or,

<head runat="server">
  
<title>Feature: ViewStateMode</title>
<meta name="keywords" content ="ASP.Net 4.0 ViewStateMode"/>
<meta name="description" content="ViewStateMode feature in ASP.Net 4.0" />
</head>

Or inside Page directive,

MetaDescription

Response.RedirectPermanent – Search Engine Friendly Webpage Redirection

In classic ASP or ASP.Net earlier than 4.0, we used to redirect to new pages or links by setting Response.StatusCode to 301 before calling Response.AddHeader method. Now ASP.Net 4.0 has provided Response.RedirectPermanent method to redirect to new pages or links with StatusCode of 301 implicitly set. Search Engines use this 301 code to understand permanent redirection from old pages links.

For example,

Classic ASP method:

<%@ Language=VBScript %>
<%
Response.Status="301 Moved Permanently"
Response.AddHeader "Location","http://www.new-page-url.com/"
%>


ASP.Net method prior to 4.0:

<script runat="server">
private void Page_Load(object sender, System.EventArgs e)
{
Response.Status = "301 Moved Permanently";
Response.AddHeader("Location","http://www.new-page-url.com");
}
</script>


ASP.Net 4.0 method:

Response.RedirectPermanent("http://www.new-page-url.com ");


Web.Config Refactoring – Custom HttpHandlers and HttpModules

Web.config now looks cleaner as most of the settings are controlled from machine.config file as ASP.Net 4.0 is all set to benefit from IIS 7 and IIS 7.5 features. When IIS is set to use .Net 4.0 and Integrated Pipeline mode, <compilation> element holds .Net version attribute. And the traditional <httpHandlers> and <httpModules> section is now shifted out of <system.web> and added inside new section <system.webserver>. All the custom handlers are added inside <handlers>, and all the modules inside <modules> section.

<system.webServer>
<!-- Add the module for Integrated mode applications -->
<modules runAllManagedModulesForAllRequests="true">
<add name="MyModule" type="WebAppModule.MyCustomModule, WebAppModule" />
</modules>
<!-- Add the handler for Integrated mode applications -->
<handlers>
<add name="MyHandler" path="svrtime.tm" verb="GET" 
<type="WebAppModule.MyCustomHandler, WebAppModule"
preCondition="integratedMode" /> </handlers> </system.webServer>


Also,

<system.web>
<compilation debug="true" targetFramework="4.0" />


Interesting point is, when we add custom handlers and modules this way, we do not have to manually configure handlers and modules in IIS again. IIS will automatically refresh itself.

Fiddler Tool and ASP.Net Applications

I have been working with one project in ASP.Net for quite long time. Most of the time, I see my colleagues fixing some problems by debugging .Net code. It is a very good way to understand application codes and .Net classes and objects. But what I feel is that Asp.net developers should equally try to know browsers they are using. When we come to browser, there comes HTTP protocol, GET/POST methods, headers, session, cache, cookies, content-type, status codes, etc. And we know all these objects are not far from Asp.net web pages or say request and response. If we know and take care of these things while debugging the application, I am sure we can save lots of time to fix the problems.

Fiddler tool can be used to know details of HTTP web request, response and many other objects that are part of web pages and browsers. Fiddler is an HTTP Debugging Proxy which logs all HTTP traffic between your computer and the Internet. But while debugging Asp.net application with Fiddler, one should not use ‘localhost’ as the machine name in the address bar; we have to use computer name or IP address.

For example,
http://Dev36/MyWeb/frmLogin.aspx is the right way, not http://localhost/MyWeb/frmLogin.aspx . Fiddler tool is easily downloadable from http://www.fiddler2.com/fiddler2/version.asp .

One thing that I found very useful about this tool is HTTP response status codes returned for all the requests made. And of course, its capability to show Parent Request, Child Requests and Duplicate Requests of any content-type. One can see from the figure shown below.FiddlerFig 1: Fiddler used to capture HTTP traffic

When we look at Result column on the left grid, we may see mostly 200, 204, 301, 404, 501, etc. like numeric codes. These are nothing but HTTP response status codes returned for each content or request type. These status codes have different meaning. I would like to summarize here in brief.

Status Codes Summary to remember:

Status Code Meaning
1xx Informational Request received and continuing the process
2xx Success Client request successfully received, understood and accepted
3xx Redirection Generally URL redirection
4xx Client Error Request contains bad syntax, IIS permissions, wrong paths of any content
5xx Server Error Server error when request arrived

1xx can be 101 or 102. Similarly, 2xx can be 204 or 206. The post fix xx will be always some numbers as recognized by HTTP standard. These results can be really helpful in debugging scenario when web pages have rich contents.

Fiddler tool is very user friendly and one will always like to use it.