Shubho on .NET

Say hello to Asp.net Razor web site. Part2 : Basic concepts

2011-03-30T22:20:00.000-07:00

Introduction

The previous part of this article introduces with an Asp.net Razor web site, which is built on top of Razor view engine. This part will cover some basic Razor stuff which would be kind of essentials to know, in order to develop an Asp.net Razor web site based application.

Here we go

As you might know already, unlike the Asp.net Web Forms, there is no Server control or CodeBehind classes available in Razor web sites. All you have is the cshtml files, which contains the plain old html markups with simple Razor expressions @. In Razor, you stay closest to the basic HTML, that gives you the power to customize the front-end functionality to your heart's content. The good news is, even though you don't have the powerful server controls here, you've got powerful built-in Helpers which lets you add complex user interface modules with functionality in the cshtml pages. Razor is simple, and beautiful.

Following are some of the basic Razor things that you should know, in order to be able to start building a real application:

The IsPost property

Like the IsPostBack property in Asp.net web forms, you can determine whether the current Request is due to a form Post or Get request by checking the IsPost property as follows:

@{  
    Layout = "~/_SiteLayout.cshtml";
}

@{
    if(IsPost) 
    {
        // Retrieve the numbers that the user entered.
        var user = Request["UserName"];
        var password = Request["Password"];
        UserManager userManager = new UserManager();
        var success = userManager.TryLogin(user, password);
    }
}

<p>Enter UserName and Password</p>
<form action="" method="post">
  <p>
    <label for="text1">UserName:</label>
    <input type="text" name="UserName" />
  </p>
  <p>
    <label for="text2">Password:</label>
    <input type="text" name="Password" />
  </p>
  <p>
    <input type="submit" value="Login" />
  </p>
</form>

Mixture of HTML and Razor

In Razor, @ is just a replacement of the server side expression <%=%> and <%...%> which are using in aspx web forms. Using the @ symbol doesn't require you to end the expression with something, which greatly simplifies the mixture of HTML markups and server side expressions and improves readability a lot.

Have a look at the following codes:

@if(IsPost) {
<p>
      You submitted data at <b>@DateTime.Now</b>
    </p> 
}
else {
   <p>
     Today is @DateTime.Now and system welcomes you
   </p> 
}

The basic rule is, you start any server side expression with @, and, you don't need to end it. All of the other programmatic syntax should be there as they should be, like, if you open the curly brace "{", you need to close it "}".

Comments

@*  A one-line code comment. *@

@*  This is a multiline code comment.     
It can continue for any number of lines. 
*@

The @Href method

For resolving correct relative paths for resources in HTML, the @Href method is your good friend. The WebPage object (The current object of the page, equivalent to the Page object in WebForms) has this handy method, which could be used as follows to resolve correct relative paths:

<link href="@Href("~/Styles/Site.css")" rel="stylesheet" />
<link href="@Href("~/favicon.ico")" rel="shortcut icon" type="image/x-icon" />

Including another page using @RenderPage()

The layout pages contain a @RenderBody() method, which is replaced by the content of a child page at run-time. Using the layout page thus gives a way to have consistent look of the entire site.

Much like the @RenderBody(), there is another way you can include the output of an another page in an existing page. The @RenderPage(PageName) method allows such facility. For example, a layout page could have a @RenderPage(PageName) to include the output of another page in it. It works much like adding a User Control in an aspx page.

_SiteLayout.cshtml

<!DOCTYPE html>
  <head>
    <title> Title </title>
    <link href="@Href("/Styles/Site.css")" rel="stylesheet" type="text/css" />
  </head>
  <body>
    @RenderPage("/_Header.cshtml")
    <div id="main">
      @RenderBody()
    </div>
    <div id="footer">
      &copy; 2010 SmartAspects. All rights reserved.
    </div>
  </body>
</html>

Passing data to Layout page

Passing data from the content page to Layout page is a very basic need. Pages in Razor has a PageData property which is used for this purpose. The following example shows passing Page title from the content page to the Layout page:

Layout Page:

<!DOCTYPE html>

<html>
    <head>
      <title>@PageData["Title"]</title>
    </head>
    <body>
        ...
    </body>
</html>

Child Page

@{  
  Layout = "~/_SiteLayout.cshtml";
  PageData["Title"] = "User details page";
}

Helpers

A helper is a component that lets you accomplish a task using a single line of code. ASP.NET includes many built-in helpers which are ready to be used in cshtml files, such as the following, which displays data in Grid layout using the built-in WebGrid helper:

@{
    var db = Database.Open("DBConn") ;
    var query = "SELECT * FROM Product ORDER BY Id";
    var data = db.Query(query );
    var grid = new WebGrid(data);
}
<!DOCTYPE html>
<html>
    <head>
        <title>Displaying Data Using the WebGrid Helper</title>
    </head>
    <body>
        <h1> Products</h1>
        <div id="grid">
            @grid.GetHtml()
        </div>
    </body>
</html>

There are many built-in helpers which you could use to achieve several necessary functions and features. Some are as follows:

The WebCache helper : Lets you using Caching in cshtml pages as follows:

@{
    var data = WebCache.Get("Key");

    if (data == null) {
        data = "Test";
        WebCache.Set("Key", data, 1, false);
    }
}

The FileUpload helper : Lets you upload single or multiple files

<html>
    <head><title>FileUpload - Multiple File Example</title></head>
<body>
    <form id="myForm" method="post"
       enctype="multipart/form-data"
       action="">
    <div>
    <h1>File Upload - Multiple-File Example</h1>
    @if (!IsPost) {
        @FileUpload.GetHtml(
            initialNumberOfFiles:5,
            allowMoreFilesToBeAdded:true,
            includeFormTag:true,
            addText:"Add another file",
            uploadText:"Upload")
        }
    </div>
    </form>
</body>
</html>

The Video helper : Lets you include a Video in the page

<!DOCTYPE html>
<html>
<head>
    <title>Flash Video</title>
</head>
<body>
    @Video.Flash(path: "Media/sample.swf",
                 width: "400",
                 height: "600",
                 play: true,
                 loop: true,
                 menu:  false,
                 bgColor: "red",
                 quality: "medium",
                 scale: "exactfit",
                 windowMode: "transparent")
</body>
</html>

The WebMail helper : Lets you send emails

@{
    try {
        // Initialize WebMail helper
        WebMail.SmtpServer = "smtp.mydomain.com";
        WebMail.SmtpPort = 25;
        WebMail.EnableSsl = true;
        WebMail.UserName = "user";
        WebMail.From = "shubho@smartaspects.com";
        WebMail.Password = "123456";
        var mailBody = Utility.GetEmailBody();
        // Send email
        WebMail.Send(to: "user@example.com",
            subject: "Newsletter for - " + customerName,
            body: mailBody 
        );
    }
    catch (Exception ex ) {
        <text>
            <b>Failed to send email.</b>
        </text>
    }
}

The Bing helper : Lets you add a search functionality with Bing search engine

@{
    Bing.SiteUrl = "www.asp.net";
    Bing.SiteTitle = "ASP.NET Custom Search";
}
<!DOCTYPE html>
<html>
    <head>
        <title>Bing Search Box</title>
    </head>
    <body>

    <div>
       Search the ASP.NET site: <br/>
       @Bing.SearchBox()
    </div>

    <div>
       <h1>Advanced Search</h1>
        Search the ASP.NET site: <br/>
        @Bing.AdvancedSearchBox(
            boxWidth: "300px",
            resultWidth: 600,
            resultHeight: 900,
            themeColor: "Green",
            locale: "en-US")
        </div>
    </body>
</html>

The LinkShare helper.
The Twitter helper.
The Facebook helper.

These let you add social network functionality in cshtml pages

The WebSecurity helper.
The SimpleMembership helper.
The ReCaptcha helper.

These let you implement user registration and login functionality with Membership

Custom helpers

You also may want to create and use custom helpers in your application and use that helper across the pages for a consistent look and functions. Here is how you can do this:

1. Add the App_Code folder in your web site

2. Create a new .cshtml file inside App_Code folder and name it Helpers.cshtml.

3. Replace the existing content with the following and save the file:

@helper BuildMessage(string user) {
    <div class="message">
      <p>
          <strong>Hello</strong>&nbsp;&nbsp; @user!
       </p>
    </div>
}

Once created, you can use the helper as follows:

<!DOCTYPE html>
  <head>
    <title>Helpers Page</title>
  </head>
  <body>
    @Helpers.BuildMessage("My test note content.")
  </body>
</html>

Further study

Enjoyed Razor? Does it seem interesting? See http://www.asp.net/webmatrix/tutorials/1-getting-started-with-webmatrix-and-asp-net-web-pages for more detailed on Asp.net Razor and keep exploring, Razor is fun.

Say hello to Asp.net Razor web site. Part1 : Introduction

2011-03-28T09:28:00.000-07:00

Introduction

Asp.net MVC3 introduces a new View Engine "Razor", which greatly simplifies the creation of view components and improves productivity. Once you have installed MVC3 from http://www.asp.net/mvc/mvc3, when you create an Asp.net MVC3 application using Visual Studio 2010, you are going to see a prompt like the following where you need to specify the View Engine (Either Aspx or Razor):

Figure : Specify View Enginge while creating an Asp.net MVC3 application

Specifying "Razor" as the view engine results in creating an MVC application based on Razor view engine where the file extensions end up with .cshtml.

Interesting thing is, once you install Asp.net MVC3, you get a new template in Visual Studio to create an Asp.net web site based on Razor view engine. Go to File->New->Web Site->Asp.net Web Site(Razor) to add a Razor based Asp.net web site in Visual Studio:

Figure : Adding an Asp.net Razor web site in Visual Studio

Doing so would result in adding the following Web Site in Visual Studio, which is based on Razor view engine:

Figure : Asp.net Razor web site in Solution explorer

Run the application using Visual Studio and you are likely to see the following output:

Figure : Home page of Asp.net Razor web site

Hm..seems good. Lets try to understand how this works!

Default.cshtml

First of all, there is no aspx in Razor, and, no server control, ascx or CodeBehind. All you see is some plain cshtml files all over the web site.

Open the Default.cshtml in Visual Studio (Which results in the above page output in browser) and you will see it contains the following markup:

Figure : Default.cshtml Markup

As you can see, it contains some plain old basic HTML and some C# scripts written in some new syntax. Yes, you got it right. Razor introduces a new simple way of writing scripts in HTML, which basically could be thought of as a simplified version of writing scripts which we were used to write in Aspx markup.

Conventionally, we used to write scripts or expressions in aspx as follows:

<% 

    var date = DateTime.Now;

%>

Current date is : <%=date %>

This expression becomes the following in Razor syntax:

@{  

    var date = DateTime.Now;

}

Current date is : @date

As a result, the markups in Razor view components (cshtml files) becomes a lot cleaner, saves a lot of key strokes for you and lets not forget this syntax is fully supported by Visual Studio intellisence. So, you are getting the best of both worlds.

Understanding _SiteLayout.cshtml

Notice the markup of Default.cshtml and you will see it contains a very minimal amount of codes. Yet it results in a good amount of output in the browser. How is that possible?

Well, the answer is _SiteLayout.cshtml. It acts like what the MasterPage does in a Web Form application and it is used in a Razor web site to define a common layout across a group of pages (cshtml files).

In Razor, if you start a cshtml file name with an underscore (_), user cannot browse the file using URL request (It is prohibited internally). The layout files are files which are to be used as an internal purpose (To define the common layout of the pages) and hence, a layout file name should always start with an underscore (_), like the default layout file _SiteLayout.cshtml.

Open the _SiteLayout.cshtml and you will see the following markups:

Figure : _SiteLayout.cshtml makrup

Notice, its just plain old basic HTML stuff along with some Razor expressions which start with @. Most importantly, notice the @RenderBody() method call in Red box. At run time, the @RenderBody() method call is replaced by the HTML markups defined in the child page (The page which includes this layout page).

So, when the Default.cshtml is browsed, the @RenderBody() method call is replaced by the HTML defined in Default.cshtml, which is nothing but the following simple HTML:

<p>

    ASP.NET Web Pages make it easy to build powerful .NET based applications for the web.

</p>

Note that, there is no restriction of name with the layout pages except the fact that, it should always start with an underscore(_). Name it as you like and everything should be alright as long as you include the layout page correctly in children pages as follows:

@{  

    Layout = "~/_MyLayoutPage.cshtml";

}

Understanding _AppStart.cshtml

If you need to run some initialization functionality when the application starts, _AppStart.cshtml is the place to do so. Unlike the layout pages, it has a standard name and you cannot rename it other than _AppStart.cshtml.

Open the _AppStart.cshtml and you would see the following markup:

Figure : _AppStart.cshtml markup

Basically, it contains some codes to initialize the database when the application runs.

Others

Expand the Accounts folder and you will see several other cshtml files implemented for User Login, Registration and other user account oriented functionality. All of these utilizes Razor syntax and use the built in helpers in Razor for rendering various UI elements or built in classes for implementing several functionality.

Like a conventional Asp.net web site, a Razor web site also can have Asp.net standard folders like the App_Data for holding database and other data sources, or, App_Codes for holding cs files. Similarly, the Razor web site can hold a reference to other class libraries to be able to invoke methods on those libraries to achieve desired functionality. Most importantly, it contains many rich built in "Helpers" which help rendering some common UI output and functionality (Like, Adding a Twitter feed, or, Social network bookmarks) which you would simply love to have!

The next post is going to cover some of the detailed stuff of Razor and I hope you would find it helpful.

Dynamic Data in Asp.net 4.0. Part3 : Customizing Dynamic Data application

2011-03-18T18:52:00.000-07:00

Introduction

This is the 3rd and last part of the article on Asp.net Dynamic Data and in this part we are going to learn how to customize a Dynamic Data application.

The previous post explains the details of a Dynamic Data application and introduces it's building blocks. Once you go through that post, you will understand how a Dynamic Data application works and this is important to learn how to customize it.

Dynamic Data lets you quickly build a data driven Asp.net application that lets you perform the CRUD functionality along with the listing and details pages without writing almost a single line of code! But, in a real worl'ds application, the CRUD (Plus listing and details pages) functionality is not enough, and, most of the cases you would need to build custom-designed pages with many other customized functionality.

One of the cool features of Dynamic Data is, it lets you easily customize the functionality at each granular level, and, there is no alien codes to customize (Unlike most other code generation framework). Customizing a Dynamic Data application is too easy once you understand how it works.

Lets start customizing it!

Scaffolding only particular tables instead of all

Find the following piece of codes in the Global.asax

DefaultModel.RegisterContext(typeof(DynamicDataEntities), 
                new ContextConfiguration() { ScaffoldAllTables = true });

Specifying ScaffoldAlltables = true in the above code instructs the Dynamic Data engine to generate codes for all tables in the data source (Be it an Entity framework data source or a Linq data source). Most of the cases this is not desired and we need some mechanism to scaffold only the tables we woul like.

To do this, perform the following steps:

Specify ScaffoldAllTables = false (Which is the default).

Let's assume the following three tables are included in the Entity (Or Linq) data context and we would like only to scaffold Employee and Address tables.

Figure : Entity Model

Add a cs file (Say, Entity.cs) in the Dynamic Data project, write two partial classes for the Employee and Address table and specify the ScaffoldTable(true) attribute for each of the classes as follows:

[ScaffoldTable(true)]
public partial class Address
{
}

[ScaffoldTable(true)]
public partial class Employee
{
}

Build and run the project. You would see that, only Employee and Address table has been included now in the Dynamic Data application and the other (Department) table is ignored:

Figure : Output after scaffolding only selected tables

Customizing display for individual fields

As you may already know, the "FieldTemplates" folder contains templates (In the form of User Controls) for most common data types. So, customizing these templates would result in a global change for the corresponding data types.

For example, the Text.ascx contains the following markup for displaying a text field:

<asp:Literal runat="server" ID="Literal1" Text="<%# FieldValueString %>"/>

If you want to display all the text fields in Green color, you can replace the above markup with the following (Assuming that you added a css class "GreenText" in the Site.css and set color : Green):

<asp:Label runat="server" ID="Literal1" Text="<%# FieldValueString %>" CssClass="GreenText"/>

After doing the change, browse the application and go to the listing page of any table. You would see the text fields all turned into green:

Figure : Customizing text field display

If you go to any other page, you would see the text color turned into green. That's some power! So now you have the field templates, and you know how to customize those to make any global change in your application. Its all yours!

Customizing display for a table data

The "EntityTemplates" folder contains the following three templates (In the form of User Controls) which determine how to display each column value of data for a particular table in Display, Edit and Insert mode.

Figure : EntityTemplates

So, changing the templates inside this folder results in changing the display of the column values for a particular table.

As an experiment, lets do a little change in the \EntityTemplates\Default.ascx like the following (Add the class="LightGrayBackground", along with adding the class LightGrayBackground in the Site.css with setting a light gray background-color):

Figure : Customizing Entity template

After doing so, run the aplication and go to the View Details page for a particular data of a table. You would see that, the background color of each cell is changed:

Figure : Output of a change in EntityTemplates

Similarly, you can customize the Default_Edit.aspx and Default_Insert.aspx to customize the layout and functionality of Edit and Insert view for the column values. Like the FieldTemplates, customizeing the EntityTemplates lets you make global changes from a single point.

Customizing pages

The "PageTemplates" folder contains the page templates, which are as follows:

Figure : Page Templates

As you know already, doing any change in any of these page templates (And their corresponding code behind classes) would result in change of display and functions in the corresponding pages.

For demonstration, just do a minor change in the Details.aspx as follows (Append the text in Red border):

Figure : Customize Details.aspx PageTemplate

Run the application and as you expected, when the details page is viewd for a particular data in a Table, the output would be now changed as follows :

Figure : Change in output after customizing Details.aspx

Like the FieldTemplates and EntityTemplates, doing any change in the PageTemplates also results in a global change for all tables in the application.

Using a customized page for a particular table

The aspx files in the PageTemplates folder are globally used by all tables. For example, the PageTemplates\Details.aspx is used to show the details page for a particular data for all of the tables. So, any customization done in these aspx files result in the corresponding change getting effected for all tables. This might not be desirable in case we need to have a specialized page for a particular table.

Fortunately, it is very easy to create a specific customized page for any particular table in Dynamic Data application. All you need is to create a folder within the "CustomPages" folder and name the folder same as the target Table name.

For example, if we want to create a customized details page for Address data, we would need to create the Details.aspx within the "Addresses" folder inside "CustomPages" folder as follows:

Figure : Customized details page for Addresses table

For simplicy, lets copy the contents of aspx markup and codes from code behind class from PageTemplates\Details.aspx and paste onto CustomPages\Addresses\details.aspx and customize the markup of CustomPages\Addresses\details.aspx as follows:

Figure : Customize Details.aspx for Addresses table

Build and run the application and go to the details page of a data in Addresses table. You would see an output like the following:

Figure : Custmized details page output for a specific table

Similarly, you can customize the other pages also for a particular table (Say, Insert.aspx, List.aspx, Edit.aspx etc) using the same approach.

Using a customized EntityTemplate (Details view) for a specific table

Like the custom pages, it is possible to define customized EntityTemplates for a particular table to display column values for a particular table. For this, you need to create templates (In the form of user controls) within the EntityTemplates folder as follows:

Figure : Customized EntityTemplate files for Addresses table

That is, you need to copy the existing EntityTemplate files and replace the word "Default" with the corresponding table name (In this cases, Addresses). Once done, customize the files as you like and see the outputs in Details/Edit and Insert views.

Using a customized field output for a particular table

Most of the cases, you would want to have the same look & feel and functionality for particular data types in your application. But, in some particular case, you might want to have customized look & feel or functionality for a particular data type for a particular table. For example, you may want to display textual field values with a border when the data in Addresses table is viewed. You need to perform the following steps to do this:

1. Copy the Text.ascx and create a new user control (Say, Address.ascx) and customize the User Control's markup as follows:

<%@ Control Language="C#" AutoEventWireup="true"
CodeBehind="Address.ascx.cs" Inherits="WebApplication2.DynamicData.FieldTemplates.Address" %>
<asp:Label runat="server" ID="Literal1" Text="<%# FieldValueString %>"
style="border:1px solid black" />

2. Create a partial class for Addresses table (If it is not there already) with a MetaData class and specify the UIHint attribute as follows:

[ScaffoldTable(true)]
[MetadataType(typeof(AddressMetadata))]
public partial class Address
{
}

public partial class AddressMetadata
{
    [UIHint("Address")] //UIHint(User Control's name)
    public string AddressName;
}

After doing the above, build the application and you will see a border around the Address data as follows:

Figure : Customize field output for table

Notice that, the borders are displayed only when the "Addresses" pages are being viewed. for any other tables, no border is going to be displayed.

Well, these are the basic customizations you might want to know about a Dynamic Data application. While building a real world application, you might learn and discover newer customzation needs and once you are used to the basic stuffs, it won't be hard for you to do those customizations. Feel free to explore the customizations and enjoy Dynamic Data.

Dynamic Data in Asp.net 4.0. Part2 :Understanding the Application project and its internal building blocks

2011-03-16T18:53:00.000-07:00

Introduction

In the previous post, we learned how to create an Asp.net Dynamic Data web application project using Visual Studio 2010 and utilize it's power to generate a CRUD application for all tables in a database. In this post we would try to understand the Dynamic Data application project structure and its internal building blocks, which would help us to customize the application later, to suit the requirement of a real world application.

When a Dynamic Data application porject is being opened in the Visual Studio 2010, it will be shown as follows in the solution explorer:

Figure : Dynamic Data application project in Solution Explorer

Except the Model1.edmx (Which has been added later as Entity data model), all other files and folders are initially created by the Visual Studio. Let's try to understand the project structure and the files/folders in this solution.

Global.asax

The Global.asax file contains the initialization codes for the Dynamic Data application and the codes are executed when the Application starts. Basically, it initializes the Data model for the application (The Entity data model in this case) using the following piece of code:

DefaultModel.RegisterContext(typeof(YourDataContextType), 
new ContextConfiguration() { ScaffoldAllTables = false });

The Entity context class name is to be provided in place of YourDataContextType (In our example, which would be DynamicDataEntities) and the ScaffoldAllTables = true has to be set in order to make sure that the Dynamic Data engine generates CRUD functionality for all tables in the Entity context. It is however possible to specify not to sfaffold all tables by keeping ScaffoldAlltables = false and doing customization so that sfaffolding applies on individual table levels only. But, for now, let's keept it simple as the customization options will be discussed in the next part of the posts.

Along with Scaffolding, the routing rule is configured in Global.asax as follows:

routes.Add(new DynamicDataRoute("{table}/{action}.aspx")
{
   Constraints = new RouteValueDictionary(new { action = "List|Details|Edit|Insert"}),
   Model = DefaultModel
});

The above code specifies that, the URL patterns for the Dynamic Data application would be of the form "{table}/{action}.aspx" (Say, Department/Edit.aspx, or, Department/Details.aspx), and, the corresponding actions would be either "List"or "Details" or "Edit" or "Insert" for the URLs. It also sets the current Data model (Model = DefaultModel) to which the routing would be applied.

Default.aspx

It is the default page which lists the tables using a GridView and renders each Table using a Hyperlink.

Figure : Table listing in Default page

Open the Default.aspx and you would see the following code:

Figure : DynamicHyperLink

As you probably figured out, in the Default.aspx, the Tables are bound to the GridView's DataSource, and, that results in displaying table names using hyperlinks, which are generated by the <asp:DynamicHyperLink/> control inside the <ItemTemplate>.

The <asp:DynamicHyperLink/> is a Server control which is used in Dynamic Data application to display links for different actions such as edit, delete, and insert. The <asp:DynamicHyperLink/> has a "Action" property which could be set either of the values "Details" or "Edit" or "Insert" or "List" and if this property value is not set, by default, "List" is assumed. So, the following URLs are rendered by the DynamicHyperLink control for the above codes in Default.aspx (Using the format {table}/{action}.aspx):

/Addresses/List.aspx

/Departments/List.aspx

/Employees/List.aspx

Just to understand a bit more, had we set Action = "Details", then the Table names would have been rendered using the following hyperlinks (Which is of course, not applicable here):

/Addresses/Details.aspx

/Departments/Details.aspx

/Employees/Details.aspx

DynamicData\PageTemplates

The "PageTemplates" folder contains the templates for the pages for the following actions:

Details (Details.aspx) : For showing details for a particular row in a table

Edit (Edit.aspx) : For showing a particular row in a table in edit mode

Insert (Insert.aspx) : For inserting a row for a table

List (List.aspx) : For listing a table data

ListDetails (ListDetails.aspx) : For listing a table data along with displaying detailed data for a particular row

Figure : PageTemplates in Dynamic Data application

Open Details.aspx and you will see that the aspx markup mainly contains following code:

Figure : Codes in Details.aspx

Notice the DynamicEntity server control. This control is a place holder control used to load a particular control from the DynamicData\EntityTemplates folder.

Note that, the DynamicData\EntityTemplates folder contains the following three user controls:

Default.ascx : Displays the columns values for a particular row in current table

Default_Edit.ascx : Displays the columns values for a particular row in current table in Edit mode.

Default_Insert.ascx : Displays input fields for a particular row in current table.

When <asp:DynamicEntity runat="server" /> is used in the Details.aspx, it is replaced by the user control \EntityTemplates\Default.ascx at run time. Similarly, when <asp:DynamicEntity runat="server" Mode="Edit" /> is used in Edit.aspx, it is replaced by the \EntityTemplates\Default_Edit.ascx and when <asp:DynamicEntity runat="server" Mode="Edit" /> is used in Edit.aspx, it is replaced by the \EntityTemplates\Default_Insert.ascx.

So, when a particular Page template is executed, in place of the <asp:DynamicEntity/> controls, a particular EntityTemplate controls gets executed for each of the row in the current Table.

DynamicData\EntityTemplates

As said already, this folder contains three user controls to display column values for a row in a Table in three different modes : Display, Edit and Insert.

Figure : EntityTemplates in Dynamic Data application

At runtime, either of these three user control replaces the <asp:DynamicEntity/> control in the Page template depending upon the Mode property value.

Open the Default.ascx and you will see the following markup

Figure : EntityTemplate Markup

The CodeBehind of this user control populates the column values for a particular row in the current table using the following code:

protected override void OnLoad(EventArgs e)
{
    foreach (MetaColumn column in Table.GetScaffoldColumns(Mode, ContainerType))
    {
        currentColumn = column;
        Control item = new _NamingContainer();
        EntityTemplate1.ItemTemplate.InstantiateIn(item);
        EntityTemplate1.Controls.Add(item);
    }
}

Now, while populating the column values for a particular row, it needs to render an appropriate control based upon the type of the column value (Say, if the column value is of a Boolean type, it should be rendered using a CheckBox, or, if the column value is of a Text type, it should be rendered using a TextBox). The EntityTemplate uses a specialized control <asp:DynamicControl/> (Mark in red above) to dynamically render an appropriate control based upon the column type of the table.

The <asp:DynamicControl/> control has a property "Mode" which could have either of the three values "Edit" "Insert" and "ReadOnly". In the Default.ascx, the "Mode" property value is not specified. On the other hand, in the Default_Edit.ascx, the "Mode" property value is set to "Edit" and in the Default_Insert.ascx, the "Mode" property value is set to "Insert" to insertuct the Dynamic Data runtime that the corresponding controls should be rendered in appropriate mode depending upon the Page (In Details.aspx, a text data should be displayed using a Label, and, in Edit.aspx, a text data should be displayed using a TextBox.

The good news is, you can decide what exact control to render for each particular column type in "Insert" "Edit" and "ReadOnly" mode. The user controls inside the FieldTemplates folder let you do this.

DynamicData\FieldTemplates

This folder contains some tiny user controls as templates to configure what specific control to render for each specific data type in "Insert" "Edit" and "ReadOnly" mode.

Figure : FieldTemplates in Dynamic Data application

At runtime, the <asp:DynamicControl/> controls are replaced by one of the user controls within the FieldTemplates folder and the specific user control is chosen based upon the data type of the column and the Mode property value of the <asp:DynamicControl/> control. For example:

Text.ascx : This user control template is used to replace the DynamicControl for columns of type varchar/text for readonly mode. It has the following markup:

<asp:Literal runat="server" ID="Literal1" Text="<%# FieldValueString %>" />

Text_Edit.ascx : This user control template is used to replace the DynamicControl for columns of type varchar/text for edit mode. It has the following markup:

<asp:RequiredFieldValidator runat="server"  ID="RequiredFieldValidator1" CssClass="DDControl DDValidator"  
ControlToValidate="TextBox1" Display="Static" Enabled="false" />
<asp:RegularExpressionValidator runat="server"  ID="RegularExpressionValidator1" CssClass="DDControl DDValidator"  
ControlToValidate="TextBox1" Display="Static" Enabled="false" />
<asp:DynamicValidator runat="server" ID="DynamicValidator1"  CssClass="DDControl DDValidator" 
ControlToValidate="TextBox1"  Display="Static" />

DynamicData\Filters

There is a Filters folder which contains three user controls (Templates) for displaying filter options for each individual rows in the listing page.

Figure : Filters

If you open the List.aspx page template you would see an <asp:DynamicFilter> controls is being used there as follows:

Figure : DynamicFilter control

The <asp:DynamicFilter/> control is used in the page markup to generate the UI for filtering table rows. Dynamic Data creates the UI by using the default filter templates that are in the \DynamicData\Filters folder. These templates support foreign-key, Boolean, and enumeration column types.

When the List.aspx page is viewed for a particular table, the Filter user controls are executed to render to filter the listing data as follows:

Figure : Filtering data in List.aspx

Others

The DynamicData\Content folder contains the resources and contents that are to be used by the tamplates. Initially this folder contains a Pager template (GridViewPager.ascx) to be used as the pagination template for the GridViews in the List.aspx, and, an "image" folder containing some images.

The CustomPages folder is initially empty. This folder would contain any custom page template that we might need to create for a particular table if we want.

Hope, this post was helpful to understand the building blocks of a Dynamic Data application project, and also to learn how the application works. The next post is going to cover the customizations options that you might need to do when you would want to use Dynamic Data for your next Asp.net application project.

Click here to learn how to customize a Dynamic Data application.

Dynamic Data in Asp.net 4.0. Part1 : Introduction

2011-03-15T08:25:00.000-07:00

Introduction

Dynamic Data in Asp.net was first introduced in .NET 3.5 SP1, and later was improved in Asp.net 4.0. For those who were longing for a RAD (Rapid Application Development) platform in Asp.net, Dynamic Data was a real good news for them. It provides a framework to quickly develop a Data Driven Asp.net application by generating CRUD functionality for the database tables. But, if you want to consider Dynamic Data as just another Code Generator tool, you are completely wrong. Generation of codes is just a part of the Dynamic Data framework. What makes it different? Well, unlike most other code generation frameworks, the framework allowes you to utilize the powerful Dynamic Data features without using the code generation based on database tables (scaffolding) at all! Most importantly, the Dynamic Data framework is so elegantly designed that its really easy for you to customize the framework generated codes at each granular level and this makes it really valuable and effective to be considered as a RAD framework to build your next Asp.net application.

In this Part1 of the article on Dynamic Data in Asp.net, I'll cover the basics and then will eventually cover the customizations which you might need to know when developing real applications.

Here we go.

Creating a Dynamic Data Application project

Assuming you are using Visual Studio 2010, go to File->New project->Asp.net Dynamic Data Entities Web Application (If you want to develop a Dynamic Data application based on Entity framework) or File->New project->Asp.net Dynamic Data Linq to SQL Web Application (If you want to develop a Dynamic Data application based on Linq to SQL) and click "OK" to let Visual Studio create the project.

Figure : Add new dynamic data project

Once the project is created, it will be shown in the solution explorer as below:

Figure : Dynamic Data project in Solution Explorer

Running a Dynamic Data Project

As Dynamic Data is a Data driven Asp.net application, it cannot be run unless we configure the data source for the application project.

Follow these steps to execute a "Hello world" run of the Dynamic Data application.

Right click on the project and Add an "ADO.NET Entity Data Model" to launch the wizerd to configure the Entity data model and specify inputs in each step until Finish.

Figure : Add ADO.NET Entity Data Model

Figure : Choose Data Model

Figure : Choose Database

Figure : Choose Database objects (Tables)

Once done, the Entity Model will be added in the solution and it will be displayed in the designer view and in the solution explorer.

Figure : An Entity data model

Figure : Entity Model in Solution Explorer

Double click on the Designer.cs file of the Entity Model (edmx) to open the corresponding Code file and expand the region "Context" to find the Entity context class name.

Figure : EntityContext class

Copy the class name (The class which inherits the ObjectContext class) for the Entity context and open the Global.asax in the Visual Studio editor to register and configure the Dynamic Data with the Entity context class.

To configure, uncomment the following line in the Global.asax (Which is commented out by default , and paste the Entity context class name (DynamicDataEntities in this example) within the typeof() operation (The first red box)

Figure : Configure the Entity Context with Dynamic Data

Also, specify ScaffoldAllTables = true (Which is by default false) to specify that the Dynamic Data engine should generate codes to perform CRUD operations for all tables in the database (Ideally, this may not be desired, but, for understanding and running the very first Dynamic Data application, lets keep this simple).

Build the Application and once build is successful, Run or Debug the application. It will launch the application which should be something like as follows:

Figure : Dynamic Data web site

Click on a particular Table name in the listing and it will show a listing page including all filtering options (For all the foreign keys) with Insert/Update/Delete links for each data

Figure : Listing page for a particular table

Using the Filter options you can filter the listing page by selecting particular filter data. The filter data are retrieved from the database using the foreign key values. Also, clicking on the "Insert new item" link below allows you to enter a new item in the system and the Edit and Delete links let you Edit a particular item and Delete one respectively.

Creating a Dynamic Data web application project and running it by configuring an Entity or Linq to SQL Data source requires 5 minutes of works at best and the end result is a powerful bug free CRUD application for the entire database generated right way.

In the next part of this article we would try to understand the building blocks of the Dynamic Data Application project, which would eventually help us customize the application when we would implement a real application using this framework.

Click Here for the next article.

Removing outer table elements from Server Control's generated HTML in Asp.net 4.0

2011-03-10T21:04:00.000-08:00

Before Asp.net 4.0, a number of Asp.net server controls used to render their corresponding HTML output within a tabular structure by surrounding the data within <table> <tr> <td> elements, and there was no way you could get rid of those tables and customize the rendered HTML. The following controls were among them:

RadioButtonList
CheckBoxList
FormView
Login
PasswordRecovery
ChangePassword

If you do a little experiment with a few of the above controls, you would see the CheckBoxList and RadioButtonList would render the following kind of HTMLs:

<table id="MainContent_CheckBoxList1">
    <tr>
        <td>
            <input id="MainContent_CheckBoxList1_0" type="checkbox" name="ctl00$MainContent$CheckBoxList1$0"
                value="1" /><label for="MainContent_CheckBoxList1_0">Shubho</label>
        </td>
    </tr>
</table>

And,

<table id="MainContent_RadioButtonList1">
    <tr>
        <td>
            <input id="MainContent_RadioButtonList1_0" type="radio" name="ctl00$MainContent$RadioButtonList1"
                value="1" /><label for="MainContent_RadioButtonList1_0">Shubho</label>
        </td>
    </tr>
</table>

And, the FormView would render the following HTML:

<table cellspacing="0" id="MainContent_FormView1" style="border-collapse: collapse;">
    <tr>
        <td colspan="2">
            Employee Name : <span id="MainContent_FormView1_Label1">Shubho</span>
        </td>
    </tr>
</table>

Guess what, these tabular HTMLs are not easy to manage using javascript and css and these also increase the overall page size because of the additional HTML elements are used to render the actual data in tabular structure.

Good news is, Asp.net 4.0 lets you get rid of these <table> elements from their rendered HTML by using some simple properties.

RepeatLayout property

For RadioButtonList and DropDownList, there is a RepeatLayout property which lets you specify an option for the HTML output. See the following options:

Figure : RepeatLayout property of RadioButtonList

If you specify "Flow", the RadioButtonList would render the following kind of HTML:

<span id="MainContent_CheckBoxList1">
    <input id="MainContent_CheckBoxList1_0" type="checkbox" name="ctl00$MainContent$CheckBoxList1$0"
        value="1" /><label for="MainContent_CheckBoxList1_0">Shubho</label><br />
</span>

Note that, no <table> element is there two wrap the above rendered HTML

Specifying OrderedList would render the HTML using <ol><li> elements and specifying UnOrderedList would render the HTML using <ul><li>. Not to mention what will happen if Table is specified :)

RenderOuterTable property

This property is available for the following Asp.net server controls to specify whether or not to render a wrapping <table> structure for the rendered HTML output. The property is applicable for the following server controls:

FormView
Login
PasswordRecovery
ChangePassword

Specifying RenderOuterTable ="false" for a FormView control results in the following HTML output:

Name
<span id="MainContent_FormView1_Label1">Shubho</span>

An issue with <asp:Login> control

Surprisingly, if you specify RenderOuterTable="false" for an <asp:Login> control, you would still see tons of <table> based HTMLs in the output. For example:

<table cellpadding="0">
    <tr>
        <td align="center" colspan="2">
            Log In
        </td>
    </tr>
    <tr>
        <td align="right">
            <label for="MainContent_Login1_UserName">
                User Name:</label>
        </td>
        <td>
            <input name="ctl00$MainContent$Login1$UserName" type="text" id="MainContent_Login1_UserName" /><span
                id="MainContent_Login1_UserNameRequired" title="User Name is required." style="visibility: hidden;">*</span>
        </td>
    </tr>
    <tr>
        <td align="right">
            <label for="MainContent_Login1_Password">
                Password:</label>
        </td>
        <td>
            <input name="ctl00$MainContent$Login1$Password" type="password" id="MainContent_Login1_Password" /><span
                id="MainContent_Login1_PasswordRequired" title="Password is required." style="visibility: hidden;">*</span>
        </td>
    </tr>
    <tr>
        <td colspan="2">
            <input id="MainContent_Login1_RememberMe" type="checkbox" name="ctl00$MainContent$Login1$RememberMe" /><label
                for="MainContent_Login1_RememberMe">Remember me next time.</label>
        </td>
    </tr>
    <tr>
        <td align="right" colspan="2">
            <input type="submit" name="ctl00$MainContent$Login1$LoginButton" value="Log In" onclick="javascript:WebForm_DoPostBackWithOptions(new WebForm_PostBackOptions(&quot;ctl00$MainContent$Login1$LoginButton&quot;, &quot;&quot;, true, &quot;ctl00$MainContent$Login1&quot;, &quot;&quot;, false, false))"
                id="MainContent_Login1_LoginButton" />
        </td>
    </tr>
</table>

At first this may seem confusing that even after specifying RenderOuterTable="false", why the HTML output is being rendered using <table> structure.

The answer is, specifying RenderOuterTable="false" only eliminates the outer table (If there is any) which wraps the original HTML control that is rendered by the corresponding server control. So, in case of <asp:Login> control, specifying RenderOuterTable="false" only eliminates the outer <table>, and, not the <table> from it's original rendered HTML (Which is above). To verify this, if you specify RenderOuterTable="true", you would see and extra <table><tr><td> is being used to wrap the original <table> based HTML output.

However, if you really want to get rid of the <table> based HTML output for the <asp:Login> control, you may do this by converting the control to a template control and specify the HTML that it should render. You can do this by going to design view and right click on the Login control and selecting "Convert to Template".

Figure : Converting a Login control to Template

Doing so would generate the template based complete HTML for the Login control which you can customize as you like.

The above is also true for the PasswordRecovery and ChangePassword control.

Hope this helps :)

Improve deployment process of Asp.net applications by generating database change scripts using Visual Studio 2010-Part 2

2011-03-06T19:35:00.000-08:00

This is the 2nd part of an article, and if you haven't gone through the first part yet, you may want to read it first. Check out the following link:

Improve deployment process of Asp.net applications by generating database change scripts using Visual Studio 2010-Part1

In Visual Studio 2010, it is possible to completely automate the deployment process of an Asp.net web application. A deployment package in Visual Studio 2010 can include dependencies on SQL Server databases, and, it is possible to generate the full database schema and also add custom TSQL scripts to run on the target SQL Server database using the deployment package.

But, this post is not going to cover the automation of deployment (Including Database Deployment) using Visual Studio. Rather, this post would demonstrate a step-by-step process to help improve the deployment process of a database driven (SQL Server) Asp.net web application by generating a TSQL change script between two different databases utilizing a Visual Studio Database project.

Here we go.

Visual Studio 2010 comes with a number of SQL Server database project template and it is possible to compare two different databases (Source and Destination databases), find out the differences between the two and generate a TSQL script that contains all the change scripts to upgrade the source database to the destination one. Once you have that TSQL script, you can run this to a target database any time to conform it to the latest version. So, gone are the days when you had to manually write scripts for each and every database change and try to troubleshoot a BUG at a newly deployed site that was usually caused by some mistake done while deploying the database.

Follow these simple steps to carry out the overall task:

Open Visual Studio 2010 and add an SQL Server 2005 Database project (Or, SQL Server 2008 Database project) by clicking File->New->Project, and expanding the Database node and selecting SQL Server.

Figure : Create SQL Server Database Project

Once the project is added in the solution, right click on the "Schema Comparisons" folder in the solution explorer and click on "Add->Schema Comparison" to add a Schema Comparison item in the project.

Figure : Add a Schema Comparison in Database project

Visual Studio will prompt you to specify the source and destination database using the following window. Check the radio button "Database" and specify the source and destination databases by clicking on the "New Connection" button.

Note:

The Source database should be the latest database where all the database changes have been done.

The Destination database should be the one which we want to be upgraded.

Figure : Source and Destination database for schema comparison

Once the source and destination database have been specified, click on the "OK" button to let the Schema Comparison tool start comparing the two databases. It would take some time to compare all objects between the two databases and would provide a schema comparison report as follows:

Figure : Schema comparison report in Visual Studio 2010

Note that, the report includes the list of objects in the source database (To the left of "Update Actions" column) and the list of objects in the destination database (To the right of "Update actions") column, and, it lets you specify your desired action for each particular object in the "Update Actions" column.

Click on the "Create" action (If there is anything such on the report) and you will see something like the following:

Figure : Create action on schema comparison report

A "Create" action indicates that, a database object is present in the source database, but, absent in the destination database. You can of course can specify "Skip" for a particular database object by clicking on the corresponding "Update Action":

Figure : Skip action on schema comparison report

Similarly, you can click on the "Update" action (If there is anything such in your report) to see what needs to be updated in the destination database and also you can specify skip if you want:

Figure : Update action on schema comparison report

The schema comparison report includes the comparison report of each and every database object between the source and destination databases (Tables/Stored Procedures/Views/Constraints/Keys/Triggers/Functions etc). So, you can have a look at each of the object in the report (Where there is a difference) and specify what to do.

Finally, you can generate the TSQL script based upon the actions you specify in the schema comparison report by clicking on the "Refresh Update Script".

Figure : Refresh Update Script

The TSQL script will be generated and it would be shown in the bottom window:

Figure : Schema comparison script

Once generated, you can execute the TSQL script to the target database by clicking on the "Write Update" action:

Figure : Write Updates on target database

Alternatively, you can export the TSQL script to an sql file, execute it later, and, possibly maintain it in the source control system by clicking on the "Export to File" action:

Figure : Export generated TSQL to a file

You can run this generated TSQL script to upgrade the target database within a quick time, and this will help you ensure a smooth deployment of your Asp.net applications because you no longer have to maintain database change scripts manually which is error prone and tedious.

Visual Studio 2010 rocks!

Improve deployment process of Asp.net applications by generating database change scripts using Visual Studio 2010-Part1

2011-03-06T01:42:00.000-08:00

Introduction

Database deployment is perhaps the most important part of any Asp.net application deployment, and, if the database deployment is smoothly done, there is a chance that the overall application deployment is done smoothly.

Most Asp.net application deployment is usually carried out in following process

Figure : Deployment process of Asp.net applications

Development Site

This is where the developers deploy their individual tasks for QA testing and fixing bugs.

Staging Site

This is where the overall application is deployed and the QA team performs production testing, once all individual tasks are passed on Development site.

Production Site

This is where the overall application is deployed once all testing on Staging site is passed.

The deployment process

Usually, source codes are maintained using a version control system (Say, SVN), and, when a deployment is required, the overall codes (From the corresponding branch) are checked out and built using a build management script (Say, NANT). Once build is successful, the binaries and other files are deployed on target server.

The corresponding database changes are also usually maintained as individual database script files within the version control system, and the build management system executes those scripts to make necessary database changes on the target database, to make sure that the database conforms to the current version of the codebase. The database change scripts include the all database related changes such as Creation/Modification of Tables/Stored Procedures/Views/Functions/Triggers and other necessary database objects.

If everything goes right, the deployment proceeds very smoothly. However, experience shows that, even if all tasks are passed on Development site, once staging deployment is done, BUGs are found and reported from the staging site (Even if the same BUG doesn't exist in Development site). Most of the cases the reason is found to be a database deployment issue. For this reason, the staging deployment is often found to be time consuming and problematic.

Why this happens?

Usually, in Development site, developers deploy their database and code related changes incrementally. That is, each developer deploys codes and the corresponding database change scripts individually. They also commit their corresponding database scripts within the source control. Now, when staging deployment is to be done, a copy of the production database is taken and copied at the Staging database server, and, the overall database change script is run there at once to conform it to the latest version of the codebase. That's where the main problem occurs.

Ideally, the database change scripts should be perfectly maintained within the source control so that whenever the scripts are run, the current version of the database at production is immediately be upgraded to the latest version, to conform it to the current source codes. But, unlike the application's source codes, the database scripts cannot be built and hence, it is hard to identify whether there is any missing database script or there is any script maintained wrongly in the source control, before the script is to be run at a target database.

So, often there are situations where it takes hours or even days for a developer to fix all the database script issues and ensure a complete staging deployment.

How to improve the situation?

There could be two possible ways to improve this situation

Option1:

Ensure a process to make sure that, no individual database change script is run on Development database. Like the staging deployment, the overall database scripts have to be run even if a single task has to be deployed there.

Pros : This will make sure that, before staging deployment, all corresponding database scripts are correctly maintained in the source control, and hence, staging deployment will likely be much quicker and smoother.

Cons : Individual task deployment at staging site would take more time than before (Because in order to deploy each little task, the overall build process has to be run).

Option2

Use some intelligent tool to generate the overall database change scripts between the database at the development site and the production site, and, run the database change script into staging database to conform it to the current codebase. Also, maintain the change script in source control.

Pros :

This will not require running the overall build process to deploy a single task on development site. Developers will just need to run their individual database change scripts.

The database change scripts doesn't have to be maintained in source control, so, this will save some time at each task level.

The staging deployment will likely to be much more smooth.

Cons : No real cons :)

The next post is all about utilizing such an intelligent tool which is available right within your favorite Visual Studio 2010!

Click here for the next part of the article.

Using Transformation files to transform web.config files for different target deployments in Asp.net 4.0

2011-03-02T02:46:00.000-08:00

Managing different web.config files for different deployment environment could be a troublesome task and synchronization of these different web.config settings could be hard.

For example, you may have the following deployment environments for your Asp.net applications for different purpose:

Local : Your own development machine

Development : Where you deploy your codes for QA testing

Staging : Where you deploy your codes for Production testing

Production : Where you deploy your codes for Production

You need to maintain different web.config files for each of these environments, and, when you need to add/delete/modify a particular setting in the main web.config file, you need to do that in all web.config files.

Along with making sure that the web.config files cotains the same set of configuration elements, for some particular configuration elements you may need to put different values for the same settings (Say, each web.config would have different Connection String values).

So, what we usually do is as follows:

1. We maintain different web config files for each different deployment environment which is something like as follows:

web.config (For local development environment)

web.config.dev (For Development site)

web.config.staging (For Staging site)

web.config.release (For Production site)

Whenever we do any change (Add/remove/modify) for a configuration element in the web.config file, we do the same change manually in all three files.

3. We put correct values for some particular configuration element (Say, Connection String) for each different web.config file.

4. Before deployment, we rename the corresponding web.config.* file to web.config and deploy.

That's not a huge amount of work we need to do, but, the problem is, there is a huge risk of getting into a situation where we might have different structure of web.config settings because we update all web.config elements manually.

Fortunately, Asp.net 4.0 has a cool solution to this problem, and, this post is all about it.

Transforming web.config files

Since Asp.net 4.0, it is possible to maintain a single web.config file and different Transformation file to manage the different web.config files for different deployment environment. The Transformation files are used by the Visual Studio to copy the original web.config file and put correct values there for generatubg an web.config file automatically for the target deployment environment.

Let us see how this is possible by following these simple steps:

Create an Asp.net Application project in Visual Studio (2010)

Figure : A sample Asp.net web application project

Go to the Build->Configuration Manager menu and add new Configuration settings Dev and Staging site

Figure : Adding new build settings for Asp.net application project

Once two new configuration settings are added (For Dev and Staging), Right click on the web.config in the solution explorer, and click on "Add Coding Transforms" to add the transformation file for each different settings.

Figure : Add transformation files

Visual Studio will generate the transformation files and the corresponding files will be shown in the solution explorer accordingly

Figure : Generated transformation files

Double click on a transformation file and the transformation file will be shown as follows:

Figure : Generated transformation file

Now, let us see an example of using the Transformation files by setting a Connection String configuration element in the original web.config and managing it's values in one of the transformation files

Open the Transformation file for Dev site (Web.Dev.Config) in the Visual Studio Editor, and, configure it by uncommenting the <connectionString> setting and specifying an appropriate Connection String property value for the settings

Figure : Specifying connection string property for Dev transformation file

Right click on the solution and click on "Build Deployment Package" to generate the web.config files based upon the Transformation file settings.

Figure : Build Deployment Package to generate web.config files from transformation files

Visual Studio will generate the transformation files within the "obj" directory. However, as is this directory is usually hidden in the solution explorer, you need to click on the "Show All Files" button to see the hidden "obj" folder in the solution explorer.

Figure : Show all files to see hidden files in solution explorer

Expand the "obj" folder as follows to find the generated web.config file from it's transformation file

Figure : Transformed web.config file generated from transformation file

Open the generated Web.config file to verify whether it contains the correct settings specified within the transformation file

Figure : Connection string value generated from transformation file

Where is the magic?

The magic is nothing but the two settings in the Transformation file, which is as follows:

Figure : Transformation Settings

The following two Transformation attribute are needed to be configured in the transformation file to generate the web.config files:

xdt:Transform : This setting instructs the Transformation engine to either Replace/Insert/Delete/Remove or Set an attribute value. In our case, we instructed to Set an attribute values for the current element by specifying the value "SetAttributes".

xdt:Locator : This setting instructs the Transformation engine to find the target element which it needs to transform. In our case, we are instructing it to find an <add> element within the <connectionString> element which has a matching name "DbConnection" in the original Web.config file (And, thereby setting the corresponding connection string value as instructed by the xdt:Transform attribute).

There are many flexible options to transform Web.config files using the xdt:Transform and xdt:Locator element, and, you can learn more on this from here.

I bet, this will make your life a little easier.

Performance Monitoring of individual Asp.net Application in Asp.net 4.0

2011-02-23T19:10:00.000-08:00

As you may know already, it is possible to monitor performance for Asp.net applications running within the Asp.net worker process (w3wp). It is as easy as adding some performance counters in the Performance Monitoring Administrative utility (Which ships with windows) and gathering some performance data for the running Asp.net applications.

However, before Asp.net 4.0, it wasn't possible to gather performance data for each individual asp.net application. So, if there were multiple Asp.net applications deployed within the same Asp.net worker process, and, if we needed performance data for a particular Asp.net application, we had no luck as we could only get consolidated performance counter data for all Asp.net applications running within the same Asp.net worker process. So, it wasn't possible to know how much memory or CPU was being consumed by a particular Asp.net application running within an Asp.net worker process.

Well, Asp.net 4.0 makes this possible. In Asp.net 4.0, the performance counters can gather data at AppDomain level (You may have to specify the following settings in the Aspnet.config file to enable this, in my case I edited the C:\Windows\Microsoft.NET\Framework\v4.0.30319\Aspnet.config file)

<?xml version="1.0" encoding="UTF-8" ?> 
<configuration> 
    <runtime> 
        <appDomainResourceMonitoring enabled="true"/> 
    </runtime>
</configuration>

Assuming you have an Asp.net 4.0 application hosted in IIS, all you have to do is to follow these steps to gather performance data for an individual Asp.net application:

1. Browse or run the Asp.net application to make sure that the corresponding Application domain is loaded within the Asp.net worker process (This is required, otherwise, the corresponding Asp.net application won't show up in the performance counter selection window).

2. In the Run command, type perfmon and hit "OK" to launch the performance monitoring tool.

Figure : Run command to launch performance monitoring tool

3. Once the Performance Monitor tool is launched, select the "Performance Monitor" node in the left panel and click on the plus sign to add a performance counter.

Figure : Add Performance Counter

4. After the "Add Counter" window is launched, expand the "ASP.NET Applications" counter and select the counter "% Managed Processor Time (estimated)". Once selected, you will see the available list of Asp.net applications (And, a few other options) in the "Instances of selected object" box from where you need to select an object which represents the Asp.net application you want to monitor. In my case, I selected the object "LM_W3SVC_2_ROOT". Once selected, click on the "Add>>" button to show up the selected counter in the right panel.

Figure : Select Performance Counter and the corresponding Object

Note : How to understand which object name represents what Asp.net application?

There could be many Asp.net applications running under the same Asp.net worker process. The corresponding object names is be shown in the format

LM_W3SVC_APPLICATION_ID_IN_IIS_APPLICATION_NAME

The APPLICATION_ID_IN_IIS is the corresponding Application ID assigned by the IIS with some numeric values like 1, 2, 3 etc, and, the APPLICATION_NAME is usually set to "ROOT" in case the Asp.net application runs directly under a web site, or, the APPLIACTION_NAME is set to the corresponding application's name if the Asp.net application runs under a web site in IIS.

You can hit the following command to list the Asp.net application information in IIS and know the Application ID of your site:

appcmd list sites

It would show you an output like the following from where you can know the Site ID of your Asp.net application:

Figure : appcmd command to list site information in IIS

5. Add another counter "Managed Memory Used (estimated)" for the same Asp.net application object, click on the "Add>>" button and then and, click on the "OK" button to confirm the counter selections.

Figure : Add Managed Memory Used (estimated) counter

The performance counter will immediately start collecting performance data and the performance graph will be shown using two different colored lines.

Figure : Performance Graph

6. Browse the Asp.net application and execute the target functionality you want to monitor performance for. The counter will keep gathering performance data.

Once you are convinced with gathering enough performance data by executing the specific functionality in your application, freeze the display by clicking on the "Freeze" button and then take a look at the graph to understand how much processing time (In terms of percentage) or Memory is being consumed by the Asp.net application.

Figure : Freeze performance counter display

Alternatively, you can switch the performance counter output to a "Report view" for a better understandability.

Figure : Switch to "Report" view to see performance data

Figure : View Report for performance data

Tracking the Memory and Processor usage at the application level gives you more granular look at resource consumption of each Asp.net application running within the same Asp.net worker process and this is really a cool feature offered by Asp.net 4.0.

Solving Debugging Timeout problem in Visual Studio and IIS7

2011-02-17T18:28:00.000-08:00

For those who wonders why debugging time out occurs in Visual Studio, and how to solve the timeout problem, this post is for them.

It was kind of irritating to see the debugging process killed automatically when debugging a web site/application in Visual Studio hosted in IIS 7, after installing Windows 7 in my PC. I wonder why that used to happen because it did never happen in case of Asp.net web site/application hosted in IIS 6.0. In first few days, I used to try to complete my debugging works in a hurry (Say, within 30-40 seconds), but, I couldn't continue this for long, and hence, decided to explore this issue a bit. Well, as it turned out, this was a matter of changing some settings in the corresponding Application pool in IIS.

Take a look at the following screen shot. This has been taken by Right clicking on the Application pool of an Asp.net web site/application and selecting "Advaced Settings":

Figure : Ping Enable property of Application pool in IIS

There is a health monitoring system in IIS (Enabled if the property "Ping Enabled=true" for the corresponding Application pool), which pings the Asp.net worker process periodically, to make sure that the process is responsive, healthy and alive. Now, when the Ping Enabled value is set to "true" (Which is by default), the debugging timeout occurs occurs in Visual Studio while debugging an Asp.net web site or application. The reason is, while debugging, the process is simply halted at the break point, and hence, it cannot response back to the health monitoring system's ping.

Now, when the health monitoring system doesn't get any response from the worker process, it immediately doesn't kill the process. It waits for the period of time specified in seconds (By the Application pool's property "Ping Maximum Response Time In Seconds") and then kills the worker process. Hence, the debugging process gets killed in Visual Studio.

So, to solve the debuggin timeout issue, either of the following two approaches could be followed:

Disable health monitoring

The easiest solution is to disable health monitoring by setting the value "Ping Enabled"=false. This would prevent the situation from happening which leads to kill the debugging process when it is unable to give any response from the health monitoring ping. This allows to be able to debug and wait at a break point for an infinite amount of time without any problem.

However, the pay off is, the health monitoring process is no longer enabled, and hence, there is no way for the administrator to get notified about any possible issues which could lead to make the web site/application down or perform sluggishly. Fortunately, in your development PC, this is probably not needed at all, and hence, disabling health monitoring could be an easy solution for you.

Increase Maximum Response Time

As said already, while debugging, when the worker process gives no response to the health monitoring ping, it waits for a certain amount of time and then kills the debugging process (Worker process). So, another approach could be to increase the waiting time long enough (Say, 600 seconds or 10 minutes) to be able to debug a particular problem. A good thing with this approach is, the health monitoring process is still enabled, and, you can adjust the waiting time as much as you need, which is handy.

Recursive Function example in SQL Server

2011-02-13T22:12:00.000-08:00

In one of my project, I had to process some information by retrieving some data in an SQL Server database which were somewhat like as follows:

There was a table ItemNames

And, there was another table named ItemNameMaps

Note that, the ItemNames table contains the name of the items and a flag IsCurrent to denote which names are currently active, and, the ItemNameMaps table contains a mapping between the OldIds and the NewIds.

When an item name is modified from the front-end, the name is not actually modified in the database. Rather, the following series of actions take place:

A new entry is stored in the ItemNames table with the modified name, along with setting IsActive = true.

A new entry is stored in the ItemNameMaps table with the newly inserted Id of the entry in ItemNames table (NewId) and the Id of the entry in ItemNames table containing the Existing name of the iteam (OldId).

The IsActive is set to false for the row in ItemNames table containing the old Name for the same item.

So, given the above data structure, the requirement was to retrieve all the old names of a given item's Id.

In the ItemMaps table, as you can see, for a given Item's Current Id (Say, 8), it is possible to know what were the Id's of the past name of the items. That is:

6-->8 (Item Id 6 was renamed to Item Id 8, A2 was renamed to A3)

4-->6 (Item Id 4 was renamed to Item Id 6, A1 was renamed to A2)

1-->4 (Item Id 1 was renamed to Item Id 4, A was renamed to A1)

So, for Item Name A3 (Id=8), we would like to retrieve the following Information:

Guess what, I retrieved the data using a recursive User Defined Function (UDF) in SQL Server.

The Recursive function

Before diving into the Recursive Function, let me derive the base logic first. For a given Item's Id (Say, 8), the data is to be retrieved using the following logic:

RetrieveOldNames(ItemId)
Begin
    OldId = Get OldId for the given ItemId From ItemNameMaps 

    Select Name (OldId) From ItemNames + Select Name FROM RetrieveOldNames(OldId)
End

Fore example, for the given Item Id = 8, the logic will execute as follows:

1. It will retrieve the OldId = 6 for the given Item Id 8

2. It will retrieve the Name for OldId 6 (A2)

3. It will call the recursive function for the OldId 6 (Go back to step 1).

Following is the actual UDF, which worked like a charm:

CREATE FUNCTION [dbo].[GetOldNames] (@Id int)  
RETURNS @OldNames TABLE (Name varchar(50))
 AS  
BEGIN 
    DECLARE @OldId bigint

    SET @OldId = (SELECT OldId FROM ItemNameMaps WHERE [NewId] = @Id)
    IF @OldId IS NULL or @OldId = 0 return 
    
    INSERT INTO @OldNames(Name)
        SELECT (SELECT Name FROM ItemNames WHERE Id = @OldId)
        FROM ItemNames
        UNION
        SELECT Name FROM GetOldNames(@OldId)
     RETURN
END

I executed the function using the following TSQL:

SELECT * from GetOldNames(8)

And, was happy to see the following result:

Dynamic typing and late binding in C# 4.0

2011-02-11T10:30:00.000-08:00

Static binding in C#

Back in C# 2.0 days, there was only static binding, or, static typing supported in the language.

That is, unlike JavaScript, or, PHP, we had to specify the type of the variables at compile time. As long as compiler was unhappy with the variable type declarations, we had to make correction of the types in order to be able to compile and run the program.

Some examples of static typing is:

int a = 5;
string s = "Hello there!";

Well, C# 3.0 was released, and, a new beast arrived in town. Talking about the keyword "var".

Initially, some people thought "var" wold allowed them to use dynamic typing. But it didn't take long to get to know the fact that, "var" was just another form of static typing, which infers it's actual type at compile time. That is,

Once you compile the following lines of codes:

var a = 5;
var s = "Hello there!";

These actually becomes the following:

int a = 5;
string s = "Hello there!";

The logic is pretty simple. The type is inferred from the value which is being assigned to the var variable. In fact, after you write the var statement correctly, Visual Studio Intellisence infers the actual type of the variable from the value.

It's obsious that, you can do the following with normal variables:

int a = 5; //Initializing the int variable with a value 5

And,

int a; //declaring the variable first
a = 5; //Assigning the variable later

But, you can't do the following with var:

var a; //Will show compile time error
a = 5;

Why? Because, as soon as compiler encounters the statement "var a", it tries to determine the actual type of "a" (Because there isn't actually type as "var", it's just a place holder type name) by analyzing the value. But, no value is being initialized while declaring the "var", and hence, error message is being shown (Doesn't matter even if you assign a value to the "var" variable later).

Dynamic binding in C# 4.0

Another new beast arrived in town with C# 4.0, the "dynamic" type. Unlike the static bound types, variables declared as dynamic are completely bound at run time. Following is a simple example:

dynamic s = "Hello there!";
Console.WriteLine(s.Length);

Even if you compile the above statements, CLR doesn't know about the actual type of the variable before actual execution of the statements.

So, Visual studio also is unable to show any Intellisense for dynamic variables. If you take the mouse on the "s.Length" on the above statement, you would see the following Intellisence:

Figure : Visual Studio Intellisence for Dynamic types

Unlike the "var", it is perfectly legal to declare a dynamic variable and then assign a value to it. That is, following statements are perfectly valid:

dynamic s;
s = "Hello world";
Console.WriteLine(s.Length);

Why this is possible? Well, for the obvious fact that, dynamic types are resolved at run time, rather than compile time. So, the complier doesn't infer the actual type while compiling the above statements, and, it doesn't complain about any problem.

This gives us the opportunity to use the same variable for different types of data. For example:

dynamic s;

s = "Hello world";
Console.WriteLine(s.Length);

s = 1;
//Console.WriteLine(s.Length); Not supported anymore. s is now an integer now
Console.WriteLine(s); //Outputs 1

However, unlike PHP, or, JavaScript, dynamic variables in C# are "strongly bound", which means, it is not possible to put two different types of data inside the same dynamic variable at the same time (Probably, using an array). PHP or JavaScript both are "weekly bound" language because they support such flexibility.

dynamic vs object

At first, these two appears to be the same, because, anything could be assigned to a variable of type object. That is, both of the followings are correct:

object o = "Hello there!";
dynamic d = "Hello there!";

But, each of the following statements are not correct:

Console.WriteLine(o.Length);//Compiler error. object class 
//doesn't have a Length property

Console.WriteLine(d.Length);//This is correct, because, at run time
//type of d is determined as string.

Use of dynamic type give you extreme flexibility in managing the variables and data of your progams, but, these are handy especially in situations when you need to accept and parse data from external sources and you are not sure about the ype of the data.

Asp.net MVP and URL Routing with WebForms. Part3 - Understanding URL Routing in Asp.net 4.0

2011-02-08T20:01:00.000-08:00

Introduction

If you have read Part1 and Part2 of this article, you already know about the fact that we've been exploring the basics of Asp.net Model View Presenter (MVP) and URL Routing in Asp.net WebForm. In this part of the article, we would learn the basics of URL Routing in Asp.net.

Well, before jumping into the details, lets ask a silly question, "What is URL Routing"?

If we are talking about a traditional Asp.net WebForm application, we already are well-aware of the fact that, if we have an aspx page at the following folder location:

\Products.aspx?CategoryId=1&ProductId=1

We need to access the page using the following url:

http://sitename/Products.aspx?CategoryId=1&ProductId=2

There is no routing taking place here. The Requested file path "/Products.aspx" is simply being mapped to the physical file location "\Products.aspx" within the web root folder of the Asp.net application.

Now, at some point some people started talking about implementing URLs which are cleaner, easy to remember, much SEO friendly and "hackable" (Parts of URL could be omitted to to get a different result). For example, instead of file extensions (Say, .aspx) and querystrings (say, CategoryId=1&ProductId=2) in the URLs they started suggesting the kind of URLs which are as follows:

http://sitename/Products/1/2

URLs as the above ones are :

Easy to remember (For obvious reasons that it is smaller, simpler and more logical).

More SEO friendly (Because it doesn't have ugly Query strings and extension which are never used in search queries in popular search engines like Google).

Hackable (Because if user hits http://sitename/Products/1, the product listing page appears with listing items having category id=1).

Now, wait a minute. A web page in Asp.net WebForms has to be an .aspx page, no matter what is the URL. Its still the same even in Asp.net 4.0 (And perhaps will remain the same). So, the Product details page would still be the same one as we had earlier (http://sitename/Products.aspx), right? If that is so, how such SEO Friendly and extension less URLs will be mapped to this actual aspx pages?

That's where URL Routing comes. In Asp.net WebForm, URL Routing means mapping incoming URL Requests (Without extension and query string) to actual aspx file along with passing necessary parameters.

The Asp.net framework (Since Asp.net 3.5 SP1 and in 4.0) has built-in support for custom URL routing which is easy enough to use and map extension less and SEO friendly hackable URLs to actual aspx pages.

What if there was no built-in URL Routing?

Pretty good question. If there was no built-in URL routing facility in Asp.net WebForm, and we still require to implement it, we had to do something like the following:

Capture each and every request probably in Application_BeginRequest() in Global.asax to map each routing URL Request to a Rout Handler class, along with specifying the target page to execute.

Create a Rout Handler class, Parse URL to retrieve parameter values and to determine the target page to execute along with passing the parameter values via HttpContext.Items and execute the target page.

Retrieve parameter values from HttpContext.Items and perform necessary executions in the Page.

The following figure depicts the basic idea:

Figure : URL Routing without Framework support in Asp.net

Frankly speaking, the above model is not that easy to implement, specially, creating the RoutHandler. Lucky that we have URL Routing facility built in now with Asp.net WebForms which have built in Rout Handler. So, all we have to do is to define the URL Mappings in Application_BeginRequest() and develop the Pages. The framework does the rests.

ABCs of URL Routing

The newly added System.Web.Routing.RouteTable class has a static property "Routes", which is of type "RouteCollection" (Which is nothing but a Generic collection of type RouteBase). The "Routes" property has two very important methods as follows:

RouterCollection routes = RouteTable.Routes;
routes.MapRoute() //For mapping to MVC controller, used for MVC applications
routes.MapPageRoute() For mapping to WebForm pages, used for MVP applications

So, in a WebForm application, the MapPageRoute() is needed to be used in the Global.asax as follows:

//Maps a URL http://mysite/Products/CategoryId/ProductId to http://mysite/Products.aspx along with
//passing the parameter values for CategoryId and ProductId
void RegisterRoutes(RouteCollection routes)
{
    routes.MapPageRoute(
    "product-info",  //Just a friendly name which could be used to refer the route later
    "/Products/{CategoryId}/{ProductId}", // URL path with Query string parameters in {}
    "~/Products.aspx"); // Actual Page which will handle and process the request
}

void Application_Start()
{
    RegisterRoutes(RouteTable.Routes);
}

Now, guess what happens when a Request arrives at Application_Start for the following URL:

http://mysite/Products/1/2

A Route entry is added to the RouteCollection for mapping the URL request to "/Products.aspx" and two parameter values are read from the URL CategoryId and ProductId. These are added to the Page.RouteData Hashtable as CategoryId=1 and ProductId=2.

The RouteHandler redirects to ~/Products.aspx and these two properties are available to retrieve in the Pages code behind as follows:

protected void Page_Load(object sender, EventArgs e)
{
    int CategoryId = Convert.ToInt32(Page.RouteData["CategoryId"]);
    int ProductId = Convert.ToInt32(Page.RouteData["ProductId:"]);
}

Or, the parameter values could also be retrieved in the Page markup as follows:

<asp:Label ID="Label1" runat="server" Text="<%$RouteValue:ProductId%>" />

In reality, these parameter values are stored in Key/Value pairs in HttpContext.Current.Items (A cache storage that could be used as long as the current Request is being served.), which are internally being accessed by Page.RouteData or RouteValue expression in markup.

Different routing examples

Routing with specifying default values and constraints

void RegisterRoutes(RouteCollection routes)
{
    routes.MapPageRoute(
    "product-info",  //Just a friendly name which could be used to refer the route later

    "/Products/{CategoryId}/{ProductId}", // URL path with Query string parameters in {}

    "~/Products.aspx", // Actual Page which will handle and process the request

    true, // Check physical URL address

    new RouteValueDictionary { //Default parameter values if not provided in URL
    { "CategoryId", 1 },
    { "ProductId", 1 } },

    new RouteValueDictionary { // Constraints specified for parameters (Has to be 6 digit numeric value)
    { "CategoryId", @"\d{6}" },
    { "ProductId", @"\d{6}" } }
    );
}

Capturing URL values with "Catch all"

For capturing any other parameter value after the URL part "/Products/1/1", there is a way to specify the parameter patterns as {*parameterName}. For example, according to the following RegisterRoutes() method, the "Details/En-US" will be captured by the "OtherParams" parameter for the following URL:

/Products/1/1/Details/en-US

void RegisterRoutes(RouteCollection routes)
{
    routes.MapPageRoute(
    "product-info",  //Just a friendly name which could be used to refer the route later

    "/Products/{CategoryId}/{ProductId}/{*OtherParams}", // {*OtherParams} will capture any value after
    // /Products/1/1
    "~/Products.aspx", // Actual Page which will handle and process the request
}

Retrieving actual URLs by route name

The friendly name (Which was provided while adding the Route) could be used to retrieve the actual URL from the RouteCollection to use the URL for redirection or some other stuff. Its as easy as follows:

string Url = Page.GetRouteUrl("product-info");
Response.Redirect(Url);

Or, there is a short-cut:

Response.RedirectToRoute("product-info");

Assigning NavigateUrl of Hyperlinks using Routes

There are a number ways to follow when a HyperLink's NavigateUrl property is to be assigned:

One approach is to assign "Hard coded" URLs as follows:

<asp:HyperLink ID="HyperLink1" runat="server" 
    NavigateUrl="~/Products/1/1"> 
    View Product Details 
</asp:HyperLink>

Or, another approach could be use Route expression as follows:

<asp:HyperLink ID="HyperLink1" runat="server" 
    NavigateUrl="<%$RouteUrl:CategoryId=1,ProductId=1%>">
    View Product Details
</asp:HyperLink>

The later approach is better because, if for any reason a route mapping is changed, you just need to modify the Route mapping in Global.asax and no where else. But, like the first case, if "Hard coded" URLs are implemented in application wide, you also need to change them in all places.

Enjoy URL Routing, its fun.

Asp.net MVP URL Routing with WebForms. Part2 - The Hello World MVP

2011-02-04T05:26:00.000-08:00

In the previous post we've discussed the background of Asp.net MVP and how it evolved. In this post we would try to understand the basics of MVP via a "Hello World" MVP example in Asp.net.

Just to recall, MVP stands for Model-View-Presenter, and, following is what they actually are:

Model is the domain or business object which encapsulates data and behavior. Model knows nothing about the two other components View and Presenter.

View is the Aspx and CodeBehind which knows about the Models, and, which doesn't contain any application logic, except displaying data from Models.

Presenter is the glue between the Model and the View, with very loose coupling. It accepts user inputs from the View, determines which business logic to execute and finally sets model to the View so that View can do the rests.

So, if we like to see a figure to demonstrate the idea, it would be something like the following:

Figure : Interactions between Model - View - Presenter in MVP

The picture is pretty self-explanatory, and, I am not describing the sequence of interactions between the different conceptual components in MVP.

Perhaps the most important thing about MVP is, Model, View and Presenter all are VERY loosely coupled. The Presenter is usually a concrete implementation, but, it doesn't directly know about the concreteView and the Model, because, it simply interacts with these two via their interfaces. This allows to change the View and the Model if required without much effect.

The "Hello World" Model View Presenter example

Following are the steps required to develop a very basic MVP example. In this example, we would implement an Asp.net WebForm application which allows user to view a User's detailed information in the output (May be by selecting a User Name from a DropDownList in a page)

Step1 : Define the Model

As has been mentioned already, Presenter is very loosely coupled with the Model via Models Interfaces. So, an interface has to be defined for the Model.

In our case, our Model is User. So, here goes the Interface:

public interface IUserModel
{
    User GetUserById(long Id);
}

And then, a concrete Model would implement this Model as follows:

public class UserModel
{
    public User GetUserById(long Id)
    {
        return db.GetUserById(Id);
    }
}

Step2 : Define the View

Like the Model, Presenter is also loosely coupled with the View, and hence, there will be an interface for the View also.

Now, an important question is, what this interface should contain?

Ideally, a View shouldn't contain any functionality or business logic. A View should only capable to get Inputs from user and show Outputs.

So, an Interface for a View should only contain properties for the Inputs and Outputs it needs to care about.

In our case, the View needs to get the User ID from user input (It gets it somehow when user selects a user in the DropDownList), and, show user's detailed information using the User object. So, the Interface should only contain the following two properties:

public interface IUserView
{
    long UserId; //For Input
    User UserDetails; //For Output
}

Who will implement this View? The codebehind class ofcourse, right?

Yes. In Asp.net WebForm application, either a Page or a User Control is a View element. So, their corresponding CodeBehind classes should implement the IUserView.

In our case, we will have a simple aspx page to display user's detailed information. So, the CodeBehind class would be something like as follows:

public class UserDetails : System.Web.UI.Page, IUserView
{
    public long UserId
    {
        //Presenter will Get UserId via this property
        get
        {
            return Convert.ToInt64(ddlUser.SelectedItem.Value);
        }
    }

    public User UserDetails;
    {
        //Presenter will set User Object via this property
        set
        {
             PopulateUserInfo(this);
        }
    }

    //Page_Load and other methods
    protected void Page_Load(object sender, EventArgs e)
    {
    }

    protected void PopulateUserInfo(User userDetails)
    {
         //Display user info in GUI
    }
}

Note that, the UserId property has only the "get" method which returns the DropDownList's selected value (After converting to long). On the other hand, the UserDetails property has only the "set" method, which is used by the Presenter to set result and thus displays user detail via the PopulateUserInfo() method.

Step3 : Define the Presenter

Before jumping into creating the Presenter class, let us ask ourselves, what should the Presenter class needs to know about?

Should the Presenter class have any property/method for setting Model(s)?

From the figure above, it is obvious that, a Presenter should know about the Models, simply because it needs to execute business logic method on those. In our case, it should know about the IUserModel, but, in reality a Presenter may need to know about multiple Models to carry out a desired operation from user inputs.

So, the Presenter should be able to access any number of Models (Well, it should access only the models it is logically related), and hence, it wouldn't be correct if the Presenter exposes some properties for setting Models (Because, it would limit the Models it can interact with). Rather, it should simply be able to instantiate any desired Model object and invoke business logic on it.

Should the Presenter class have any property/method for setting View?

Yes it should! Why? Simply because, the result has to be displayed via one single View component only, be it a User Control or an aspx page. If the Presenter knows about the View it needs to interact with, it can gather user input from it's corresponding property, and, set the resultant output to the corresponding property.

So, there will be a Constructor inside the presenter class to accept a View. The Presenter will have a method to execute business method on the Model to get the result and set it to Views result property as follows:

public class UserPresenter
{
    IUserView view;
    public UserPresenter(IUserView view)
    {
        this.view = view;
    }

    public void ObtainUserDetails()
    {
        //Get input from User
        long userId = view.UserId;
        //Execute business method on Model to obtain result and set to View's property
        IUserModel model = new UserModel();
        view.User = model.GetUserById(userId );
    }
}

Step4 : Let the play begin!

Once you carried out the above steps, you are ready for the show. In our case, we would ask the Presenter to carry out what it should do when user wants to see the detailed information of a User by selecting the target user's Name inside a DropDownList. Following is the modified CodeBehind code:

public class UserDetails : System.Web.UI.Page, IUserView
{
    public long UserId
    {
        get
        {
            //Presenter will Get UserId via this property
            return Convert.ToInt64(ddlUser.SelectedItem.Value);
        }
    }

    public User UserDetails;
    {
        set
        {
             //Presenter will set User Object via this property
             PopulateUserInfo(this);
        }
    }

    //Page_Load and other methods
    protected void Page_Load(object sender, EventArgs e)
    {
    }

    protected void PopulateUserInfo(User userDetails)
    {
         //Display user info in GUI
    }

    void ddlUser_SelectedIndexChanged(Object sender, EventArgs e)
    {
        //Instantiate Presenter object with setting this Page as it's view
        UserPresenter presenter = new UserPresenter(this);
        //Ask the Presenter to do what it should do
        presenter.ObtainUserDetails();
    }
}

That's it! You just learned the simplest Model View Presenter Pattern implementation in Asp.net WebForm.

In the next part of this article, we would learn the basics of URL Routing with Asp.net WebForm with some routing examples and other related things.

Stay tuned.

Asp.net MVP and URL Routing with WebForms. Part1 - The Background

2011-02-03T03:13:00.000-08:00

Introduction

Lets get back to Asp.net 2.0 days.

One of your clients wants to implement SEO friendly URLs in his/her application. That is, instead of the URLs containing messy query string parameters:

http://www.mysite.com/products.aspx?category=book

He/she wants to see the URLs which look a lot cleaner and more SEO friendly:

http://www.mysite.com/products/book.aspx (No Request parameter)

Or, he/she would be even happier with the following kinds of URLs

http://www.mysite.com/products/book (No Request parameter and no Extension)

Back in Asp.net 2.0 days, How did you implement such a requirement?

Let me answer this for you.

Those days IIS didn't support extension less URLs (IIS 6.0) and Asp.net MVC didn't born yet. So, we had to use the following widely used trick:

URL Rewriting

This trick is usually applied to convert the URLs with Query String parameters to the following types of URLs (Which ends with an extension) in Asp.net applications.

http://www.mysite.com/products/book.aspx

The trick is to intercept each and every Request and use HttpContext.RewritePath(), which does nothing but re-writing (Overwriting) the URL of the current HttpRequest with the original page URL within the current HttpContext, resulting in execution of the original page, instead of the incoming request. The client remains un-aware of this fact because he/she doesn't see and URL change in the browser address bar.

The operation is carried out in following steps:

User hits http://www.mysite.com/products/book.aspx in the browser

The request is intercepted at Asp.net and the URL is re-written in the HttpContext pointing to the original page http://www.mysite.com/products.aspx?category=book

The original page gets executed and response is being sent to browser, the current URL http://www.mysite.com/products/book.aspx at the browser remains unchanged.

At the very basic level, the following approach is usually being followed:

void Application_BeginRequest(object sender, EventArgs e)
{
  string fullOrigionalpath = Request.Url.ToString();
  if (fullOrigionalpath.Contains("/Products/Books.aspx"))
  {
    Context.RewritePath("/Products.aspx?Category=Books");
  }
  else if (fullOrigionalpath.Contains("/Products/DVDs.aspx"))
  {
    Context.RewritePath("/Products.aspx?Category=DVDs");
  }
}

Some pluggable HTTP Modules are available to implement such URL re-writing in a cleaner and manageable approach, which allows to configure the mappings of incoming URLs to actual URLs using patterns/regular expressions, which is very handy.

Now, what about URLs without any extensions, like the following?

http://www.mysite.com/products/book

Back in Asp.net 2.0 days, IIS 6 didn't support mapping extension less URLs to Asp.net execution engine. So, this had to be done with some tricks to map any incoming Request in IIS (With any extension) to Asp.net by using WildCard setting in IIS.

So, a carefully engineered WildCard mapping with URL re-writing (Along with managing some other issues, such as handling PostBacks, Handling static requests for static resources etc) , it was possible to get the job done, despite the fact that, it wasn't a very easy thing to do.

Asp.net MVC and IIS 7

Well, MVC was totally new. The Model View Control concept was seen to be released as a framework, which allows to de-couple the user interfaces, control application flow with URL Routing and separate data, presentation and business logic using some built-in libraries available in Asp.net, perform unit-tests on the Controller, View and Models, which wasn't easy (Or, wasn't possible) to do so in WebForms. But perhaps the biggest different between the Asp.net WebForm and MVC from end-user's perspective is the extension less URLs which are much SEO friendly, makes more sense to the end-user and which are much cleaner (No URL parameters and no extension if IIS 7 or heigher is used).

Well, the BAD news was, it was no longer possible to use the rich Data bound and other server controls that we used to love so much in Asp.net WebForms. In MVC, there is no Page life cycle, ViewState or server side controls. Just plain basic HTML stuff. Stunning, right?

Yes it was. Despite the fact that Visual Studio does provide a quick start Asp.net MVC application structure with some pre-built Model-View-Controllers (And, some framework classes to do some common stuff easily), being not able to use the server controls any more was seemed to be a real BIG loss. It was kind of sacrificing the productivity and richness of Asp.net WebForms to get URL routing with support of separation of concerns (Model-View-Controller). To lot of people (Specially people like us, the developers), this wasn't really very encouraging.

So, some people thought "How about doing something that allows to get the bests of both world. To be more specific, how about combining the power of URL routing and Separation of concerns (Provided by the MVC concept) with Asp.net WebForm?".

This simple thought gave birth to the concept of Asp.net MVP.

What is Asp.net MVP?

Asp.net MVP stands for Model View Presenter. Its roughly has the same concept that MVC has, with some minor differences (A bit more loose coupling). But, the biggest issue is, unlike the Asp.net MVC, Asp.net MVP is not a framework. Rather, it is nothing but the classic Asp.net WebForm with a conceptual change of working with the components which we are used to work with. In this concept, there will be Models, Views and Presenter where:

Model is the domain or business object which encapsulates data and behavior. Model knows nothing about the two other components View and Presenter.

View is the Aspx and CodeBehind which knows about the Models, and, which doesn't contain any application logic, except displaying data from Models.

Presenter is the glue between the Model and the View, with very loose coupling. It accepts user inputs from the View, determines which business logic to execute and finally sets model to the View so that View can do the rests.

Using the Model View Presenter approach in Asp.net WebForm allows to separate the concerns where the CodeBehinds doesn't contain any business logic, the application flow is controlled by the Presenter and the data is encapsulated by the Models, along with the great advantage of being able to use Asp.net server controls and their immense power to build rich functionality.

So, Asp.net MVP concept allows to build Asp.net applications by using the concept of separating the concerns using the traditional Asp.net WebForms, which is definitely good. But perhaps the most important highlight of Asp.net 3.5 SP1 and onwards is the addition of URL routing facility which allows to map the incoming URL requests to (With the advantage of extension less URL in IIS7 and onwards) any aspx or Controller class, which gives the flexibility of working fully in MVC way with utilizing the full power of Asp.net Web Forms. The URL Routing allows to customize and route the incoming URLs in the same way Asp.net MVC allows to do so, and, the MVP concept allows to implement the application functionality using separation of concerns approach and utilize the full power of Asp.net server controls to build rich user interfaces rapidly.

In the next parts of this article we would explore the URL Routing facility of Asp.net Web Form and utilizing this to develop a simple application in MVP approach. Stay tuned for that.

Using HttpContext.Current.Items as a data storage for current HttpRequest

2011-01-26T01:22:00.000-08:00

Did you ever use HttpContext.Current.Items?

Chances are there you didn't. Why? Because this is a least known thing which people talks about, but, this could be a good friend of you "in need". Let's see what this is and how this could be used effectively to carry out our works in better approach.

When an HttpRequest arrives at an Asp.net application, the Request is processed and the result is usually served back to the browser (Or, client application) as HTML output. Since Asp.net receives the Request, it goes though lots of steps. For example, it could go though the following steps:

Application_BeginRequest in Global.asax (If defined)
Init event in custom HttpModules (If defined)
Page_Load other life cycle events events in a Page
Page_Load other life cycle events events in a Master Page
Page_Load and other life cycle events in User controls
Method invocation on Dlls

While the Request is traversing through these steps, what if at step1 we have some data that we need to make available when the Request is traversing step2?

Lets see some examples where we may need to implement such requirement:

Example1

Suppose, we have an Application_BeginRequest() event handler at Global.asax which is executed for each Request, and, we retrieve some data from somewhere within this method:

void Application_BeginRequest(object sender, EventArgs e)
{
    //Retrieve some data from somewhere for each Request
}

Now, we need to make sure that this data is available to the target Page which will get executed, to avoid to load the same data again in the Page. How would we pass the data to the Page?

Example2

Suppose, we have a user control which retrieves data from the database using an expensive operation. Once the user control finishes executing, the data is to be served to another user control which does some other stuff with the same data. How could we pass the data from this user control to another user control?

Example3

Perhaps we have some data at the Page_Load event (Say, current user object), which we need to make available to each and every method that get executed on the Business and Data access layers and we don't really want to modify each and every method to accept a new parameter just because we need to make the data commonly available to all methods. What do we do?

I know, there are alternatives. We may use different approaches while we deal with each above examples. The easiest and most general approach which is being used in such cases is as follows:

Store the data in Session in Step1
Retrieve the data from Session in Step2
Clear the data from Session in Step2 (Clear it because this Session data is not required for any other Request)

Unfortunately, the Session state is being misused in such approach. Session should be used to store data which are required for the current Session, not for the current Request, and hence, this is not obviously a best practice to use in such cases. Also, if someone forgets to clear the data from the Session at Step2, a BUG is given birth to the system.

Well, the good news is, HttpContext.Current.Items is the perfect solution for such scenario. This is a simple HashTable which lets you store and retrieve data as long as the HttpRequest is alive and traversing through different steps in its life cycle.

So, you could use HttpContext.Current.Items to store data in one step and retrieve later in other step as follows:

//Store data in Step1:
HttpContext.Current.Items.Add("Key", "Value");

//Retrieve data in Step2:
object value = HttpContext.Current.Items["Key"];

This HashTable could be considered as your Cache storage as long as the Request is being processed. This is a good friend indeed and be friend it with, and get benefited.

Understanding ClientIDMode="Predictable" in Asp.net 4.0 with Examples

2011-01-24T10:52:00.000-08:00

Introduction

If you are an Asp.net developer, you may already be well-aware of the fact that, Asp.net 4.0 lets you control how the ID property value of the server controls gets generated in the HTML markup. Before version 4.0, this wasn't possible, and, the ID property value of all server controls used to be generated using the nesting structure of the control hierarchy using some complex syntax which was not so readable and usable.

It was very common to see a server control's ID property value to be generated as follows:

<input name="ctl00$MainContent$GridView1$ctl04$TextBox1" type="text" 
value="Matin" id="ctl00_MainContent_GridView1_ctl04_TextBox1" />

Frankly speaking, we, the developers used to not to bother too much about these generated ID's in the HTML markups. Why? well, we somehow got used to the fact that the generated ID's were not really usable and if we ever needed to access any element on client side, we either used to add some custom properties to the server controls, or, used JQuery with using some searching pattern to find out the element we need and do the rest. Well, it wasn't a "very hard thing to do", but, it was something we had to do each time we need to access elements on client side, and, this used to require some more time to finish our works.

Let us see an example. suppose we are in need of showing some Employee information using a GridView as follows:

Figure : A simple GridView showing some listing data

Lets assume the requirement is to show the user's name (Or, may be to show user profile) when user clicks the "View" button.

Let's look at the XHTML Markup of the GridView:

<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False" ShowHeader="false">
    <Columns>
        <asp:TemplateField>
            <ItemTemplate>
                <asp:TextBox ID="TextBox1" Text='<%#Eval("Name") %>' runat="server"></asp:TextBox>
                <asp:Button ID="Button1" runat="server" Text="View" />
            </ItemTemplate>
        </asp:TemplateField>
    </Columns>
</asp:GridView>

As you can see, the Name property value of each employee is being shown using a <asp:TextBox> server control, and, an <asp:Button> control is used to display the "View" button on the browser. Both these are inside the <ItemTemplate> element to ensure that, the TextBox and the Button is displayed in each row.

Now, according to the requirement, we need to display the employee profile (Only "Name" in this case) when the "View" button was clicked. For simplicity, let's assume that the "Name" is to be displayed via an "alert" message.

We have a problem

In order to show emplyee's Name using Javascript, we need to access the TextBox of the corresponding row. Question is, when a Button is clicked on a particular row, How do we access the Name of the Employee inside a TextBox on the same row using JavaScript?

We need to know the TextBox client ID, right? Let's see how we manage this.

Here is the HTML that gets rendered in the browser for the GridView:

Figure : Rendered HTML for GridView

As you can see, the ID of the TextBoxes and ID of the Buttons (Marked in red border) are generated by Asp.net, and, these ID's are not really "Predictable" for use while we are writing server side codes. It is obvious that, the generated ID value depends on the hierarchy of the server controls in which the are nested.

Naturally, it is hard and unreliable to write client side scripts (javascripts) to read the value of other element in the same row, in such situations. So, to avoid guessing client IDs of element in the same row, a common strategy was to "feed" the client ID of the elements in the server side code.

Not clear? Well, let's see how we used to manage the overall implementation for this example:

1. Define an "OnRowDataBound" (or similar) event method to the data bound control, which gets fired when each data is bound to the data bound control.

In our case, we used to add the following event to the GridView:

<asp:GridView ID="GridView1" runat="server" AutoGenerateColumns="False" ShowHeader="false"
onrowdatabound="GridView1_RowDataBound">
...
</asp:GridView>

2. Find target controls inside this event method (Which gets fired for each row) and add an "onclick" javascript method as an attribute of the Button control along with passing the necessary values as method parameter:

protected void GridView1_RowDataBound(object sender, GridViewRowEventArgs e)
{
    if (e.Row.RowType == DataControlRowType.DataRow)
    {
        Employee emp = e.Row.DataItem as Employee;
        if (emp != null)
        {
            Button button = e.Row.FindControl("Button1") as Button;
            if (button != null)
            {
                button.Attributes["onclick"] = string.Format("return ViewDetails('{0}')", emp.Name);
            }
        }
    }
}

3. Define a JavaScript method to display the necessary information (Employee name in this case)

function ViewDetails(Name) 
{
    alert(Name);
    return false;
}

Not very elegant, right?

ClientIDMode control property in Asp.net 4.0

In Asp.net 4.0, a new property called "ClientIDMode" has been added the the Control class which lets you control the ID values for the Server controls the way you like. To be very specific, if you set the ClientIDMode="Predictable" (With some other minor settings), you know in advance what the exact client ID of the server controls will be (No matter what nesting structure the control is within, and, no matter which DataBound control uses them). This is really handy if you need to access those element using some client side scripts like JavaScript.

Before seeing a practical example of this property value, let us see the possible options of this property:

ClientIDMode="AutoID"

The classic mode, which is default. ID's are generated by Asp.net run time using the existing logic.

ClientIDMode="Static"

Lets you specify a static ID for the server control, which remains unchanged no matter where the server control is used. Also makes sure that, any nested/child server controls doesn't use this contro's ID as a part of thier ID values.

ClientIDMode="Predictable"

Lets you control the client ID values the way you like, with some other property settings. More on this later.

ClientIDMode="Inherit"

Specifies that, the control should inherit the ClientIDMode from it's immediate parent server control

The ClientIDMode could be configured in the Application level (in web.config), or, in the Page level, or, in the Control level.

So, let us see how the ClientIDMode property could be used to control the client IDs for the nested server controls which are used inside a DataBound control (In our example, GridView).

The same GridView markup is now as follows:

<asp:GridView ID="GridView1" Visible="false" ClientIDMode="Static" ShowHeader="false" ClientIDRowSuffix="Id" AutoGenerateColumns="False" runat="server">
    <Columns>
        <asp:TemplateField>
            <ItemTemplate>
                <asp:TextBox ID="TextBox1" ClientIDMode="Predictable" Text='<%#Eval("Name") %>' runat="server"></asp:TextBox>
                <asp:Button ID="Button1" runat="server" ClientIDMode="Predictable" OnClientClick='return ViewEmployeDetails(this.id)' Text="View" />
            </ItemTemplate>
        </asp:TemplateField>
    </Columns>
</asp:GridView>

Using the ClientIDMode property

Lets try to understand the facts with this Markup:

The GridView has ClientIDMode = "Static". This implies that the GridView's ID will be "GridView1" and no child server control's Id will have "GridView1" as part of their ID values.

The TextBox1 has ClientIDMode = "Predictable". This implies that the TextBox's ID will be of TextBox_X format. Here the value of X depends on another property of the DataBoundControl (ClientIDRowSuffix). If ClientIDRowSuffix property is not configured, X is just a sequence of values starting from 0 (TextBox_0, TextBox_1 and TextBox_2 here). On the other hand, if ClientIDRowSuffix property is configured with a property name of the Entity with is being bound (ClientIDRowSuffix="Id" here), X is replaced by the value of the corresponding property (TextBox_ID in this case).

The Button1 also has ClientIDMode = "Predictable". So, the same rule also applies here as above.

So, if we have an Employee class as follows:

public class Employee
{
    public int Id
    {
        get;
        set;
    }
    public string Name
    {
        get;
        set;
    }
}

And, if we initialize the GridView with some Employees as follows:

protected void Page_Load(object sender, EventArgs e)
{
    var Employees =
    new List<Employee> {
        { new Employee { Id = 10, Name = "Shubho" } },
        { new Employee { Id = 11, Name = "Titu" } },
        { new Employee { Id = 12, Name = "Matin" } }
    };

    GridView1.DataSource = Employees;
    GridView1.DataBind();
}

The HTML that gets generated now is as follows:

Figure : HTML markup that gets generated using ClientIDMode property

Note that, ID of the Text boxes are getting generated in the pattern "TextBox1_X" property (TextBox1_10, TextBox1_11 and TextBox1_12), and, ID of the buttons are getting generated in the same pattern(Button1_10, Button1_11 and Button1_12).

Also note that, because we used ClientIDRowSuffix="Id" for the GridView, the X values are replaced by the ID of the Employees. If we didn't use this property, the value of X would be replaced by a sequenece number starting from 0 and the generated Id's for the text boxes and the buttons would be (TextBox1_0, TextBox1_1 and TextBox1_2) and (Button1_0, Button1_1 and Button1_2) respectively.

So, here is the benefit of having the control ID's having a predictable form:

As each Button has the form Button1_X and each TextBox has the form TextBox1_X, when user clicks a button, we can get the corresponding Employee ID by replacing the "Button1_" with a blank string "". Once we know an Employee's ID, we can construct the ID of each control in the same row which has ClientIDMode="Predictable". That is, we can construct the corresponding TextBox ID as "TextBox_" + ID.

To simplify this further, we can just replace "Button1" with "TextBox1" in the Button's ID to get the corresponding TextBox ID. Once we know the ID of the TextBox, accessing it's value is a matter of child's play.

So, here is the JavaScript method definition that we used as an "OnClientClick" handler for the Buttons:

function ViewEmployeDetails(idOfButton) 
{
    var idOfTextBox = idOfButton.replace("Button1", "TextBox1");
    alert(document.getElementById(idOfTextBox).value);
    return false;
}

As you can see, no need of define any "OnRowDataBound" event method now just to attach JavaScript methods as attributes with necessary parameters, and, setting the ClientIDMode and related property values does the work. This lets us get rid of the extra works that we required to do earlier, adn thus save some of our valuable times and let us feel that we are now able to work smarter then earlier.

Smart work from Asp.net 4.0 team!

HTTP Error 404.13 - Not Found : The request filtering module is configured to deny a request that exceeds the request content length

2011-01-22T03:00:00.000-08:00

I was developing an application that allows user to upload files to the server using the <asp:FileUpload/> control. In order to make sure that users can upload large files, I configured the web.config as follows to allow larger files to be uploaded (The default setting is 4 MB):

<httpRuntime maxRequestLength="512000"/><!--To allow up to 500MB-->

While testing the file upload functionality from within the visual studio development server (Right clicking on the aspx file and selecting browse), I found it working quite fine. But surprisingly, after hosting the Asp.net web site onto IIS (IIS 7), I found the file uploading functionality was no longer working, and, it was broken while trying to upload large files (I was trying with a file over 40MB in size). Following is the screen shot of the error message that I got:

Figure : The error message from IIS while trying to upload a large file

The error page also suggested me to do the followings:

"Verify the configuration/system.webServer/security/requestFiltering/requestLimits@maxAllowedContentLength setting in the applicationhost.config or web.config file."

So, as suggested, I did the following configuration in the web.config of my Asp.net web site(By setting maxAllowedContentLength value in Bytes):

<system.webServer>
  <modules runAllManagedModulesForAllRequests="true"/>
  <security>
    <requestFiltering>
      <requestLimits maxAllowedContentLength="512000"></requestLimits>
    </requestFiltering>
  </security>
</system.webServer>

Guess what, it didn't work out! After modification when I tried to upload the file again, the same problem occured again. What happened?

According to the error message, the web.config or applicationhost.config should be configured according to the above suggestion. Modifying web.config didn't work out. So, the applicationhost.config could be modified to see what happens.

Wait a minute! the applicationhost.config is the configuration file of IIS (IIS7.0 or heigher). Does that mean IIS has a Request size validation?

Yes it has. Until IIS 7.0 there was no Request size validation, but since IIS 7.0, the Request length is verified by IIS first, before deliverying the Request to Asp.net.

So, to be true, it doesn't really make any sense to increase the maxAllowedContentLength value in web.config. The Request dies even before reaching the Asp.net. So, whatever is to be configured, it has to happen at IIS.

Well, as I figured out, there are two ways you can configure this value in IIS:

1. Configuring the applicationhost.config

Open the %WINDIR%\System32\inetsrv\config\applicationHist.config in editor and specify the following configuration within the security/requestFiltering section(By setting maxAllowedContentLength value in Bytes):

<requestFiltering>
      <requestLimits maxAllowedContentLength="512000000"></requestLimits>
</requestFiltering>

Note:

Modifying the above configuration worked for me in one PC (Running Windows 7+IIS 7.0), but, didn't work on another one (Running Windows Vista + IIS 7.0). After configuring the applicationHost.config file, I tried to upload the large file and the same error message was appearing again. I don't know why, but, if you have the same experience, applying the following approach (Configuring via IISManager) would definitely work.

2. Configuring via IISManager

Open the IIS Manager and select the site or application you need to configure in the left panel

Select "Features View" and double click on the "Request Filtering" icon.

Figure : Request Filtering

Note :

If you can't find the "Request Filtering"icon, you need to install the IIS Administration Pack from this link : http://www.iis.net/download/AdministrationPack. This is a lightweight installation which shouldn't take too much time on a decent internet speed.

Double clicking on the "Request Filtering"icon will bring up the Request filtering configuration window. Right click on the window and select the "Edit Feature Settings" option:

Figure : Edit Feature Settings option in IIS

Finally, specify the Maximum allowable content length (In Byte) in the following window and click "OK" to save:

Figure : Specifying Maximum allowable content length in Bytes

This worked perfect for me and I was able to upload the large file now without any problem. Hope, this will work for you too :)

Exception Handling best practices in N-Tier Asp.net applications

2011-01-19T02:27:00.000-08:00

"How do you manage Exceptions in your Asp.net applications?"

Pretty simple question, but not that much simple to answer.

We are good at making things. But, may be, we are not equally good at designing systems which properly handles errors with gracefulness, provides user with a polite message about the error and doesn't leave him/her in a dead-end, and internally, notifies the system developers with enough details so that the poor developers don't feel like they need to learn some rocket science to fix those errors.

If you ask me how do I define a good Exception management for an Asp.net application, I would tell you the followings:

Your system has a good exception management if:

It doesn't show unnecessary technical error descriptions when an error occurs, rather, apologize to user with a screen that something went wrong and lets him/her go back to the system.

When an error occurs, it immediately notifies technical teams with detailed information for troubleshooting, along with logging error details.

It has exception management done in a central and manageable manner without unnecessary try..catch...throw spread across the overall code base.

So, if we want to ensure a good exception management in our Asp.net application, we need to meet these three high level objectives.

The bare minimum thing you should do

If you are the laziest developer in the world (Like what I was a few years ago), you should at least take advantage of what Asp.net offers you to handle exceptions gracefully. All you need is to perform the following two simple steps:

Enable customError in web.config:

As you might know already, this little configuration instructs the Asp.net run time to redirect to Error.aspx whenever an error occurs in your Asp.net application. Setting mode="On" instructs to redirect always, which may not be a good choice if you are developing your system. Setting mode="RemoteOnly" should be perfect choice for you as this results in redirection to the error page only when page is browsed from a remote machine.

Define an error page:

You obviously need to create an error page, right? The Error.aspx page you may like to have is as follows:

Figure : The simplest error page

So, I created the Error.aspx as follows, in my Asp.net web site created using Visual Studio 2010:

Markup:

<@ Page Title="Home Page" Language="C#" MasterPageFile="~/Site.master" AutoEventWireup="true"
    CodeFile="Error.aspx.cs" Inherits="Error" >



    
        
        

        
        

        Go back

CodeBehind:

public partial class Error : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        Page.Title = "Error occurred";

        string PreviousUri = Request["aspxerrorpath"];

        if (!string.IsNullOrEmpty(PreviousUri))
        {
            pnlError.Visible = true;
            hlinkPreviousPage.NavigateUrl = PreviousUri;
        }
    }
}

After performing these two steps, whenever an unhandled exception occurs now, Asp.net run time will redirect the current request to the error page (In this case, Error.aspx) with a query string parameter "aspxerrorpath" with the value being set with the previous page URL. So, Error.aspx.cs is able to read the previous page URL from this request parameter and display a graceful error message with a "Go back" hyperlink to let the user go back to the previous page.

To test whether it works or not, I created an Exception scenario as follows:

User browses Default.aspx and clicks on "Do Something"button.

The Button click event handler method throws an Exception.

Asp.net run time catches this Exception and redirects the user to the Error page.

It works pretty fine as expected.

Who will fix the error?

Very important question. Its good that your system now gracefully handles exceptions. But this isn't enoug, right? We need a mechanism to catch the exceptions and notify our technical team or log the exception details somewhere so that they can analyze and fix the error as early as possible.

So, we need a way to capture the Exceptions and do something of our own. Let's see how we can do that.

Page.OnError()event method on CodeBehind class

Each Asp.net Page CodeBehind class inherits the System.Web.UI.Page class and can override the OnError() event of the base class. Doing this lets the page capture any unhandled exception using the following piece of code:

protected override void OnError(EventArgs e)
{
        Response.Redirect(string.Format("Error.aspx?aspxerrorpath={0}",Request.Url.PathAndQuery));
}

As we typically have multiple pages in our Asp.net applications, it would be smarter if we define the OnError() inside a base class (Say, BasePage) for all CodeBehind pages as follows:

public class BasePage : System.Web.UI.Page
{
    public BasePage()
    {
        //
        // TODO: Add constructor logic here
        //
    }

    protected override void OnError(EventArgs e)
    {
        //Report Error
        Exception ex = Server.GetLastError();
        ErrorHandler.ReportError(ex);
        Server.ClearError();
        Response.Redirect(string.Format("Error.aspx?aspxerrorpath={0}",Request.Url.PathAndQuery));
    }
}

This would allow us to get rid of implementing OnError event method on each and every CodeBehind pages.

Application_Error() event in Global.asax

As you might know already, you can define Application level events inside the Global.asax file, which lets you define a global error handler event method Application_Error(). If you define an Application_Error() event method in this file, each and every unhandled exceptions will be captured by this event method and you can do whatever you want. In our case, primarily we would want to report the exception details inside this event method, along with redirecting user to the error page:

void Application_Error(object sender, EventArgs e)
{ 
        // Code that runs when an unhandled error occurs
        //Report Error
        Exception ex = Server.GetLastError();
        ErrorHandler.ReportError(ex); //Notifies technical team about the error
        Server.ClearError();
        Response.Redirect(string.Format("Error.aspx?aspxerrorpath={0}",Request.Url.PathAndQuery));
}

If you handle exceptions via the Application_Error event handler at Global.asax, you do not need to handle exceptions via the Page.OnError() event handler. So, life gets event easier.

Shouldn't the Exceptions be handled in CodeBehind classes?

This is a good question. One can obviously suggest to handle Exceptions in the CodeBehind classes as follows:

try
{
    //Do some stuff
    businessObject.SaveObject(object);
}
catch(Exception ex)
{
    ErrorHandler.ReportError(ex); //Notifies technical team about the error
    Response.Redirect(string.Format("Error.aspx?aspxerrorpath={0}",Request.Url.PathAndQuery));
}

But, the CodeBehind classes could have many codes which could invoke methods on some other tiers and, Exceptions could be thrown from those methods. Moreover, there will be many CodeBehind classes. So, in the above manner, the try..catch Exception handling codes has to be written in hundreds of places (Not to forget the fact that, if we need to change in Exception handling mechanism, we also would require to change the codes in hundreds of places). Does this really sound a smart thing to do when we can handle the Exceptions from within a central place (Application_Error())? Absolute no.

So, DO NOT WRITE any try..catch block inside the CodeBehind classes and keep it absolutely free of any ugly error handling mechanism (Well, there may be an exception to this suggestion, will see shortly). Utilize the power of Asp.net and keep your Exception handling mechanism simple and manageable from a central place.

I have an N-Tier Asp.net application. How should I handle exceptions?

This is a classic question. Multi-tier applications are pretty common these days, and, what should be a proper exception handling policy to follow in such applications? Should we handle exception in each tier using try...catch blocks? Should we throw exceptions from a tier to an upper tier? Should we log exception inside each tier?

I would try to simplify the answers as follows. You should do whatever is required to meet your high level objectives. That is, error reporting to the technical team and graceful exception handling to the end-user. You also need to make sure that you are not writing some repeating codes to handle the exceptions in multiple places.

So, let us try to derive an exception handling policy for an N-tier Asp.net application by analyzing our high level objectives, and, using some common sense.

We need to handle Exceptions gracefully

It doesn't matter how many tiers we have in our Asp.net application. As long as we have an Application_Error event defined in Global.asax, nothing can escape it. So, no matter where an Exception occurs in our multi-tier application, the Exception will be captured in Global.asax and it would do whatever it has been instructed to do (Redirect user to an error page).

We need to notify Exception details to technical team

Yes, the Application_Error event method also reports exception details to the technical team via some mechanism. But, wait a minute! Should we really need to notify the technical team about each and every exception? may be not.

What are the exceptions we need to report to the technical team?

Suppose, a Data Access Layer method is being invoked in the DAL layer (A separate dll) within our application, and, the DAL method may throw an exception from the database. Should we report such Exceptions from the Data Access Layer to the technical team? Obviously yes.Why? Because the error has to be fixed in the Database routines.

If any unhandled Exception (Say, a NullReferenceException) is being thrown from any part of the codes (Be it generated from within the CodeBehind classes, or, from any other tiers) should it be reported to the technical team? Obviously yes. Why? For the same very reason that the error has to be fixed in the codes with some good defensive programming.

Now, suppose we are taking an input from the user and invoking a business method with the input parameters. The business method expects a particular parameter value to be within a certain range. If it doesn't fall into that range, it throws an Exception with an appropriate message. Should we report this kind of exceptions to the technical team? Obviously not. Why? Because, this exception is usually thrown with an intention to let user know that he has done something wrong and the exception message is used to guide him/her to do the right thing.

Also, suppose a ThreadAbortException is being generated as a result of using Response.Redirect() in the CodeBehind classes. Should we notify the developers about this exception after capturing inside the Application_Error event handler? Obviously not. Why? Because, this particular exception is not being generated as a programmatic or system failure, and, there is nothing to fix.

So, in a multi-tier application Exceptions could be generated from each tier, and, these exceptions could be of different general categories, and, based upon their category these Exceptions need to be handled in different approach. Some particular category of exceptions are needed to be reported to some particular technical teams, some particular category of exceptions need not to be reported to any technical team, rather, these are to be used to guide user to use the system correctly, and, some particular category of exceptions just needed to be ignored. So, this generates a need to develop an Exception hierarchy which could be used commonly across all different tiers within the application.

Exceptions generated from each tier would be categorized according to their corresponding general type (When an Exception occurs, this would be done by wrapping an Exception with a particular type of Exception from the Exception hierarchy) and will be thrown to the upper tier so that, an exception management policy can determine the category of the exceptions and handles those judiciously.

The custom exception hierarchy

Following could be a very basic Exception hierarchy that could be used to wrap up the original exceptions and categorize them so that, these exceptions could be handled using a good exception management policy.

Figure : A basic custom Exception hierarchy

The Exception class names are self-explanatory. They all inherits a base exception class BaseException which itself inherits the Exception class.

So, this Exception hierarchy may be used as follows:

Inside DAL methods:

Catch any Exception that might get thrown by invoking database operations, wrap it inside a DALException, and throw to the upper tier.

public List<User> GetUsers()
{
    string SP = AppConstants.StoredProcedures.GET_ALL_USERS;

    IDataReader reader = null;
    List<User> users = new List<User>();
    try
    {
        using (DbCommand dbCommand = Database.GetStoredProcCommand(SP))
        {
            using (reader = Database.ExecuteReader(dbCommand))
            {
                while (reader.Read())
                {
                    User user = User.CreateFromReader(reader);
                    users.Add(user);
                }
            }
        }   
    }
    catch(Exception ex)
    {
        throw new DALException("Failed to retrieve User.", ex);
    }
    return users;
}

Inside business methods:

Generally, we need not to handle Exception inside the business methods while calling this (Or any) DAL methods. Why? Because, the DAL methods are already handling exceptions. So, whenever any exception occurs while invoking a DAL method from the business methods, the exception will be propagated to the call hierarchy across the upper tiers, and will be caught by the global exception handler Application_Error().

So, you just invoke the DAL method as follows in one of your business methods:

public List<User> GetUsers()
{
    UserDAO userDAO = new UserDAO();
    List<User> users = userDAO.GetUsers();
    if(users != null)
    {
        //Do other stuffs 
    }
    //Do other stuffs
    return users;
}

But, as has been said already, we may need to throw some custom exceptions inside a few business methods as follows (To let the caller notify that a certain condition has to be met in order to proceed the operation):

public void Add(User user)
{
    if(user.Age &lt; 18)
    {
        throw new BLLException("Not allowed for kids!"); 
    }
    UserDAO userDAO = new UserDAO();
    userDAO.Add(user);
}

Inside CodeBehind classes

Only Exceptions of type BLLException are to be handled here. Why? because, BLLException actually represents a business logic validation error (With a validation error message, see above example) which is needed to be displayed to the end-user to guide him/her to provide correct input or carry out his/her operations correctly. If we do not handle BLLException in the CodeBehind classes, these exceptions will be propagated to the global error handler Application_Error and it will either ignore the exception, or, report the exception to the technical team, neither of which is desired.

So, following is how we may handle the BLLExceptions in CodeBehind classes:

protected bool AddUser()
{
    UserManager userManager = new UserManager();
    User user = PopulateUserFromInput(); 
    try
    {
        userManager.Add(user);
    }
    catch(BLLException ex)
    {
        ShowErrorMessage(ex.Message);
        return false;
    }
    return true;
}

Inside Application_Error() event in Global.asax

Well, when an Exception is bubbled up to this global exception handler method, it could either be a ThreadAbortException, or, a DALException, or, a BLLException or, an unhandled exception for which we didn't catch it using any try...catch block inside our Application.

This Application_Error event handler method would be interested to handle only DALException and any unhandled exceptions. As we know already, it would report the exception details (Probably will send emails about the exception to some pre-configured email addresses, and, log the exception details somewhere). It would simply ignore the ThreadAbortExceptions (Because, nothing to be fixed) and BLLException (Because, this is actually a custom exception which should be handled inside the CodeBehind classes to show validation message to the user).

This is how the Application_Error event method could look like:

void Application_Error(object sender, EventArgs e)
{
    Exception ex = Server.GetLastError();

    if (ex as System.Threading.ThreadAbortException != null &amp;&amp; ex as BLLException != null)
    {
        //Do not handle any ThreadAbortException or BLLException here
        //Only handle other custom exception (DALException in this example) 
        //and any other unhandled Exceptions here

        ErrorHandler.ReportError(ex);
        Response.Redirect(string.Format("Error.aspx?aspxerrorpath={0}", Request.Url.PathAndQuery));
    }
}

Asp.net and Microsoft Exception Handling Application Block

You can use the Exception handling Application Block provided my Microsoft, which can suit your need perfectly. You can define exception policy for each kind of exception in declarative manner, and, you can configure the block to how to act to each kind of exception. Once installed, you can configure the Application Block using GUI tools right within the Visual Studio.

This link could help you configuring the Exception Handling Application Block in your Asp.net application. I found it handy.

Conclusion

Remember these simple rules while you design your Exception handling mechanism in your N-Tier Asp.net applications:

Define a Global exception handler, report exception details to the technical team via an exception reporting mechanism (Probably with sending emails and logging the exception) and redirect the user to an Error page with a polite message and provide him/her link to get to the original page.

Categorize the exceptions using an exception hierarchy which suits your need and define a well-thought out policy to deal with each category of Exception.

Let all exceptions be propagated to the global exception handler, except the custom exceptions (BLLException in this example) which are meant to be showing an error message to the user to guide him/her carrying out his/her works correctly.

Once an exception is thrown (Be it thrown by you or by the CLR) from any tier from within your N-tier application, catch it only at a single place (Be it at CodeBehind classes or global exception handler) and DO NOT re-throw it after you catch. Throw once, Catch once.

Remember, plan before you do. Laying out a clean well thought-out Exception handling mechanism in your N-tier Asp.net application would let you run your system smooth, and let you know about any error that is to be fixed immediately when it happens. The end result is, your development team, management and the client, everybody is happy.

Performance Profiling in Visual Studio

2011-01-17T01:44:00.000-08:00

Did you know you could get rich performance profile information from right inside your favorite Visual Studio?

You want to ensure your application runs as fast as possible, and one of the most important thing is you need to know which part of your application is taking most amount of time (Or, resources) to execute, so that, you can identify the areas where you need to optimize performance. Well, this wasn't easy, until Visual Studio introduced the "Analyze" menu in the top-right portion of the IDE.

Figure : Performance profiler menu in Visual Studio 2010

Assuming that you have opened your application on Visual Studio (In my case, I created a sample Asp.net application) clicking on the "Launch Performance Wizard" menu will launch the performance profiler wizard for you with the following window:

Figure : Select profiling method

Note that, there are 4 options. Visual Studio recommends the CPU sampling (Which periodically interrupts the target process and collects information from call stack to develop profiler information), but in our case we will most likely choose "Instrumentation" which injects some instrumentation codes within each method of the dlls (Of the target application which we are profiling) for collecting performance data in terms of method level execution time. This profiling method is very handy for identifying the performance issues for database based applications (For example, you can measure performance of your DAL methods and identify which stored procedures are taking what amount of time in which conditions).

Selecting the "Instrumentation" option and clicking on the "Next" button would bring up the following wizard step:

Figure : Select type of module to profile

This wizard step asks to select a "module" for profiling. You can profile any exe, dll or an Asp.net web site/application and you need to provide the path to the exe or dll, or, you need to provide the URL of the Asp.net web site/application.

In our case we are profiling a sample Asp.net application which is currently opened in the visual studio. The sample Asp.net application has an About.aspx page containing the following simple CodeBehind:

public partial class About : System.Web.UI.Page
{
    protected void Page_Load(object sender, EventArgs e)
    {
        TestMethod();
    }

    private void TestMethod()
    {
        Thread.Sleep(300);
    }
}

Note that, our target is to profile the performance of the methods within the CodeBehind class (TestMethod() in this case). So, we would proceed with the default selection of the web site and click "Next", which would bring up the following wizard step:

Figure : Enable Tier Interaction Profiling

This wizard step asks you to enable Tier Interaction Profiling (TIP) which lets you get the execution time the application spent on each Tier. We would like to check this check box and click "Next" to proceed the last wizard step:

Figure : Final step to start profiling

Click on "Finish" and Visual Studio will launch the application with hitting a URL of your application in the browser and will start profiling with showing the following activity in the screen:

Figure : Profiling application

In order to profile the particular page functionality in About.aspx, I needed to hit the corresponding URL in the browser (Because, Visual Studio didn't hit this URL automatically):

Figure : Browse page to profile

Visual studio will start profiling the page functionality and keep showing the following kind of information in the output window (Regarding the instrumentation codes it is injecting within the dlls of the web application):

Figure : Visual Studio instrumenting application dlls

You need to perform the desired functionality in your target page (Which you are profiling) so that Visual Studio can profile the related back-end methods. In my case, I just need to profile the methods which are executed when the page loads. So, as this is done, I need to close the page in the browser so that Visual Studio finishes gathering profile data and generates report. Alternatively, you can always stop or pause profiling and generate profile report if you want.

Figure : Performance Profile report

The profile report will be generated and opened by Visual Studio and there will be three following sections being displayed in the Summary View of the report (Which is default selected).

Figure : CPU usage timeline

The first section of the profile report shows CPU usage percentage in the timeline (The overall time taken by Visual Studio while profiling this page). This doesn't give necessary information we are seeking.

The second section of the profile report shows the "Hot Path" information. This means, it displays the most expensive call path of the method chain, and, elapsed time (Percentage) in terms of Inclusive and Exclusive. "Inclusive" means, the corresponding method execution time is being shown including the time taken by all child methods execution time. "Exclusive" means, the corresponding method executing time is being shown excluding the time taken by all child methods.

Figure : Hot path

The third portion of the performance report shows methods/functions invocation information which had consumed most execution times (In terms of percentage among the overall page execution time).

Figure : Function invocation with most execution time

Switch to the "Functions" view in the drop-down list to see the method level absolute performance (In terms of ms) of the related methods:

Figure : Switch to Functions view

The following Grid will appear containing the execution time of each method which were involved in overall execution of the page:

Figure : Function execution time

Note that you can sort the grid by the "Elapsed Inclusive Time" field to see which methods are consuming the most amount of execution time. You can also export the Grid in some format to analyze performance issues later.

Switch to "Tier Interactions" view from the drop-down list to see the execution time taken by the application in each different tier.

Figure : Select "Tier Interactions" view

The following Grid will display the execution time and the number of occurrence taken in each different tier:

Figure : Tier interaction report

As this is a sample Asp.net application having minimal functionality, the performance report doesn't provide too much significant performance measurement information. But, I hope, this post was able to help you getting the idea of profiling your application from right inside your favorite IDE-the Visual Studio.

Happy profiling.