August 2009

Upto Visual Studio 2008, one can set the Title of the page declaratively or through program using Page.Title.  However, as more and more web traffic is happening through search engines, Page’s Title, Keyword and description become more important.  Although the Keyword feature was exploited and hence many search engines today ignore it, Page Description is something still major search engines such as Google, Bing use for identifying and indexing pages based on content.

The new feature in ASP.NET 4.0 allows users to programmatically set the Page Description and Keywords as follows:-

protected void Page_Load(object sender, EventArgs e)

this.Page.Title = “My ASP.NET Blog”;

this.Page.MetaKeywords = “ASP.NET, Web Development, Blog, ASP.NET Blog”;

this.Page.MetaDescription = “This Blog contains posts related to ASP.NET and Web Development”;


The above code appends the following markup

<meta content=”ASP.NET, Web Development, Blog, ASP.NET Blog” />

<meta content=”This Blog contains posts related to ASP.NET and Web Development” />

And the way it works is that, if the meta tags are already present in the HTML markup, whatever is set in the code behind  will fill up the “content” part alone if the “name” tag is matching.

Although this looks simple, it is very useful in cases where you want to set these dynamically based on a condition / criteria.  So far, these were set statically in the HTML.  Now with Page Class level access, these can be set dynamically.


ASP.NET 4.0 has many improvements for different set of scenarios such as Webforms, Dynamic Data & AJAX based web development.  There are also a lot of enhancements to the core runtime that powers ASP.NET such as Caching, Session & Request/Response objects.

For this post, we will examine some of the web form enhancements.  There are sure a lot of them and we will examine some of them in the future posts.

Controlling View State using the ViewStateMode Property – Performance Enhancement

One of the most complained thing in ASP.NET Webform is the growing viewstate which becomes a concern for performance.  While earlier you can set the EnableViewState property to true or false, post that, all the controls, by default inherit and even if you set it to enabled at control level, the behaviour was inconsistent.

With ASP.NET 4.0, the ViewStateMode property helps to determine for every control, whether the ViewState should be enabled, disabled or inherited accordingly.  Ex.-

<asp:Panel ID=”pnlViewState” runat=”server” ViewStateMode=”Disabled”>
Disabled: <asp:Label runat=”server”  Text=”Value set in markup” ViewStateMode=”Inherit” /><br />
Enabled: <asp:Label  runat=”server” Text=”Value set in markup” ViewStateMode=”Enabled” />
<hr />
<asp:button ID=”Button1″ runat=”server”  Text=”Postback” />

In the code-behind

protected void Page_Load(object sender, EventArgs e)
if (!IsPostBack)
label1.Text = “Value set in code behind”;
label2.Text = “Value set in code behind”;

When you run the above page, you can find that the intial value for both the labels is set to “Value set in code behind” whereas after clicking on the button (postback), the value of label1 changes to “Value set in markup” whereas the value of label2 remains unchanged.  As you can see, the Panel which holds both these lables has ViewStateMode set to Disabled and label1 is inherting the mode (this is the default if not specified) and label2 has it enabled.  That is the reason label2 maintains viewstate while label1 loses it.

While it is arguably possible using the simple EnableViewState property earlier, it was never consistent.  Considering the fact that in most of our performance sessions, we talk about disabling viewstate and then enabling it at control level while it doesnt work, this ViewStateMode is a welcome architectural change to improve performance.

Debugging the SharePoint Timer job was really a tough job for me, i searched on the web and found so many solutions but they did not work at my system (i dont know why). Finally i did a trick to debugg the timer service, i added the following line of code in the timer service job where you want to have a break point:


after compiling the solution and restarting my timer service it came with the following popup options :


  • Abort– means you want to stop timer service instance
  • Retry- means you want to debugg the code
  • ignore- means ignore this message and continue the execution of the code

for debugging i selected retry and it opened another screen


selected new instance of CLR debugger, it showed the following screen


after pressing F10 two times it did enable debugging like this


here i did normal debugging by pressing F10 and F11 keys


you can also use breakpoints here


hope this helps

if you think this is helpfull , dont forget to leave a comment.

Sometimes you want your web page to ‘stay alive’. That is, if a user is filling out a complicated form, that may contain several fields, you do not want the session to time out before they are finished.

It’s not simply a matter of increasing the session timeout to a very large value. If you do that, the sessions would be left active in the server memory for hours—long after the visitors have left the site. Increasing the session timeout IS a solution… but not necessarily a good solution.

The goal is that the session should stay active as long as the web page is open on the client machine …even if there are no post backs to reset the session timer. When the web page is closed, the session should time out normally.

I implemented a solution for this: The client will “ping” the server at intervals of less than the session timeout which will reset the session timer. This is known as the Heartbeat design pattern

For testing purposes, I set the Session Timeout to two minutes in web.config:

<sessionState timeout=”2″></sessionState>

to trace the output of defferent events i used “System.Diagnostic.Debug” class.

To watch the Session State events, I added debugging strings to the global.asax file:


Here is what the output looks like without the heartbeat:


We need a method at the server for the client to call. We use a WebMethod.

  1. There must be a ScriptManager on the page.
  2. The ScriptManager must have EnablePageMethods set to true.
  3. The WebMethod must be public and static.
  4. The WebMethod must have the EnableSession attribute set to true.



Here is the output with the heartbeat:


It looks like the session is staying alive while the client is idle: Excellent!

I hope someone finds this useful.

if this is helpful, dont forget to leave a comment.