Migrating ASP.NET MVC 1.0 to MVC 2.0: Real World Scenario

As most of you have noticed, ASP.NET MVC v.2.0 has been released last month. The new version introduces lots of cool features, so most of the existing MVC 1 applications will be upgraded to the new release. In the current post I will try to share my experience with migrating existing ASP.NET MVC 1.0 application to MVC 2.0.

Scenario: There is an existing ASP.NET MVC 1.0 web application build on top of .NET Framework 3.5, jQuery and Visual Studio 2008. The goal is to migrate the application to MVC 2, while keeping the other libraries and tools (.NET 3.5, VS2008, etc).

Identifying the breaking changes

The first step from the process would be to check the ASP.NET MVC 2.0 breaking changes. Naturally after carefully evaluating each item in the breaking changes list, I have find out that the following will be a problem: “JsonResult now responds only to HTTP POST requests”. The problem was caused by a jQuery plug-in that uses only HTTP GET. So the solution was to:

• Replace the plug-in by someone more configurable that can use HTTP POST. You should do it in case that your application exposes sensitive information and is vulnerable to the attack described here.
• Explicitly allow HTTP GET on JsonResults. You can do it by using the JsonRequestBehavior.AllowGet

[AcceptVerbs(HttpVerbs.Get)]
public JsonResult GetData()
{
    //Some other code
    return Json(data, JsonRequestBehavior.AllowGet);
}

I was lucky that the information exposed in my application was not sensitive, so I decided to use the JsonRequestBehavior.AllowGet.

Migrating the solution to build against ASP.NET MVC 2.0

Being confident that I have resolved all breaking changes I had to think about migrating the solution to use the new version of MVC 2.0. If you don’t want to do everything by hand, you should use this tool. The tool is build by one of the Microsoft employees and works GREAT. However, I have noticed a few gotchas. The tool insists to backup your project before the conversion. This seems redundant, because usually the source code stays in code repository and if somehow the conversion produces a mess, everything could be restored. After all I had to wait a few extra minutes for the backup (more than 1GB in my case). The second issue that I have found is the update of the jQuery files. The tool updates the jQuery and Microsoft AJAX libraries. Since the web site was relying on several other 3rd party jQuery plug-ins I didn’t want the jQuery upgrade. So I had to manually remove the update. Despite of the above, the tool is absolutely FANTASTIC an you will need it.

Running the application

Up to now, everything went pretty well and the solution compiled without problems. So I was ready to run it. After hitting F5 I was stunned. The application started to close and open pages by itself! With the help of a few unit tests and Goolge I was able to identify the source of the problem. It turns out that there is another undocumented breaking change: a value from TempData dictionary will be removed after the request in which it is read! You can read more here. The fix was relatively easy and soon everything was working as usual.

Bottom line

The migration process from ASP.NET MVC 1.0 to MVC 2.0 is relatively easy and you should do it. The new features are awesome.

ASP.NET MVC Best Practices – Routes to Ignore

Routing is a key feature from the ASP.NET MVC. If you are not familiar with this concept, take a look here, because I’m not going to explain it. I’m going to share some routes that you should ignore in your configuration.
So maybe you are wondering, why should I ignore some routes? And the simple answer is: Because most of the time, different search engines/crawlers/bots will try to index your site and they will request for specific files. For example, Google will try to access the following file: http://yoursite.com/robots.txt. The robots.txt file is used to to give instructions about your site to web robots. More info can be found here. Up to now, everything sounds great, but if your site does not have robots.txt file, the ASP.NET MVC framework will raise an exception upon a request like the above. So your log, where the unhandled exceptions are reported can be flooded with messages like:
System.Web.HttpException : A public action method 'robots.txt' could not be found
on controller 'YourPage.Controllers.YourController'.
Obviously, there are two ways to handle this – provide a dummy robots.txt file or instruct the ASP.NET MVC framework to ignore such URL’s. I prefer the second approach. In this post I will try to summarize all the URL’s that should be ignored by the ASP.NET application. So, here they are:

• ~/robots.txt
  
• ~/sitemap
  
• ~/sitemap.gz
  
• ~/sitemap.xml
  
• ~/sitemap.xml.gz
  
• ~/google_sitemap.xml
  
• ~/google_sitemap.xml.gz
  
• ~/favicon.ico
  
• ~/mobile
  
• ~/iphone
  
• ~/apple-touch-icon.png
• ~/sitemap.txt
• ~/sitemap.rss
• ~/trafficbasedsspsitemap.xml
  

You need to ignore the routes above, ONLY if your site do not uses such a file. If you are not familiar with the sitemaps concept,  here is a quick overview that answers to most of the questions.
Here is the code, taken from the Global.asax.cs file that should ignore some of the URL’s outlined above:

public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

routes.IgnoreRoute("robots.txt");
routes.IgnoreRoute("sitemap");
routes.IgnoreRoute("sitemap.gz");
routes.IgnoreRoute("sitemap.xml");
routes.IgnoreRoute("sitemap.xml.gz");
routes.IgnoreRoute("google_sitemap.xml");
routes.IgnoreRoute("google_sitemap.xml.gz");
routes.IgnoreRoute("favicon.ico");

//Rest of the code is ommited
}

I will update the list above as soon as I find a new URL that should be ignored, so stay tuned. As well you are welcome to contribute to this list by posting a comment.

Some SharePoint 2010 Articles

Few months ago I have installed the beta version of the SharePoint 2010. The product looks really cool, although some of the requirements like: “must have Windows 2008 64bit” are really annoying.

In the past few weeks I have published some articles in one new site dedicated to SharePoint technologies called SharepointMonitor.com. If somebody is interested, here is the list:

• Building Approval Workflows with SharePoint Server 2010
• Building Custom Workflows using SharePoint Designer 2010
• Difference between WSS 3.0 and MOSS 2007
• Getting Started with the SharePoint 2010 Excel Services

I have plans for several other articles, so stay tuned. I will update this post when something new comes out.

NHibernate: Display executed SQL at the bottom of an ASP.NET page (MVC or WebForms)

Almost every modern application that uses relational database is build on top of ORM tool. The ORM tools can significantly decrease the efforts for interacting with the database, but unfortunately most of the developers are not familiar with the SQL code that is produced by the ORM tools. I’m not hiding that my favorite ORM is NHibernate. I’m using it since early beta, but from time to time even I’m surprised by the produced SQL. So, you need to monitor closely what SQL is executed. This blog post will describe one not widely used but very useful approach – the executed SQL will be displayed as a footer on any ASP.NET web page. It does not matter if the web page is using MVC or WebForms. Interested? Then continue reading.

Currently, there are several ways to display the SQL produced by NHibernate:

• Database profiler tool – some of the modern RDBMS systems are coming with a profiler tool that can hook to the database engine and display the executed SQL. For example SQL Server comes with SQL Server Profiler. Unfortunately the SQL Server Express edition is missing this tool.
• NHibernate Profiler – this is a third party tool that hooks to your application and monitors the NHibernate. Comes with cool WPF UI interface and lots of other features. Unfortunately at the time of writing you will need to purchase a license to use it. As well you will need to switch from your application to the tool after each action to monitor the produced SQL.
• Log4Net – you can configure the log4net library to save the produced SQL to a file for example. Unfortunately reading long files with SQL statements is too boring. Sometimes it is tricky to figure out the SQL executed as a result of single action.
• Display the executed SQL at the bottom of an ASP.NET web page. The idea is to have an IHttpModule module that will inject the SQL code at the end of each request. This approach saves time, because the SQL is visible instantaneously after the action is executed. Unfortunately this trick works only for web applications.

There are several ways to access the SQL that has been executed by NHibernate. I will use a NHibernate interceptor. The code for the interceptor looks like this:

public class NHibernateSQLMonitor : EmptyInterceptor
{
    public static void Init(Configuration config)
    {
        config.SetInterceptor(new NHibernateSQLMonitor());
    }

    private static StringBuilder mExecutedSQL = new StringBuilder();

    public static string ExecutedSQL
    {
        get
        {
            return mExecutedSQL.ToString();
        }
    }

    public static void ClearExecutedSQL()
    {
        mExecutedSQL = new StringBuilder();
    }

    public override NHibernate.SqlCommand.SqlString OnPrepareStatement(
        NHibernate.SqlCommand.SqlString sql)
    {
        mExecutedSQL.AppendLine(sql.ToString());

        return base.OnPrepareStatement(sql);
    }
}

The important method is OnPrepareStatement. This method is invoked every time NHibernate executes SQL statement. The sql parameter holds the SQL that will be executed.

Before using it, the interceptor must be registered. One possible way to do it is like this:

NHibernate.Cfg.Configuration cfg = new NHibernate.Cfg.Configuration();
NHibernateSQLMonitor.Init(cfg);

ISessionFactory sessionFactory = cfg.BuildSessionFactory();

Now everything is ready for our IHttpModule that will inject the executed SQL at the bottom of a web page. Here is the implementation:

public class NHibernateSQLMonitorModule : IHttpModule
{
    public void Init(HttpApplication context)
    {
        context.PostRequestHandlerExecute += new EventHandler(
  PostRequestHandlerExecute);
    }

    void PostRequestHandlerExecute(object sender, EventArgs e)
    {
        HttpContext httpContext = ((HttpApplication)sender).Context;
        HttpResponse response = httpContext.Response;

        if (response.StatusCode == 302)
        {
            //Browser performs redirect. Do nothing.
            //The executed SQL will be shown on the next page
        }
        else if (response.ContentType == "text/html")
        {
            response.Write("<hr>");
            response.Write("<b>SQL Executed by NHibernate</b>");
            response.Write("<br>");

            string executedSQL = NHibernateSQLMonitor.ExecutedSQL.Replace(
   "\n", "<br>");
            response.Write(executedSQL);

            NHibernateSQLMonitor.ClearExecutedSQL();
        }
    }

    public void Dispose()
    {
        //Not required
    }
}

Now there is one final step that should be done – the HttpModule needs to be registered in the config file of the application. To do it open the web.config file, find the <httpModules> section (<modules> if you are running IIS7) and place the following line there:

<add name="NHibernateSQLMonitor"
 type="Data.NHibernateSQLMonitorModule, Data"/>

Data is the assembly name where the NHibernateSQLMonitorModule class is defined. Now everything is ready and if there are no compilation errors you should see something like this:

After adding new record, the page will look like this:

So, what about improvements:

Instead of using NHibernate interceptor for monitoring the executed SQL it is possible to display the output from the Log4Net. The log4net output contains the SQL parameter values which may be a great benefit. As you may have noticed, the values in the screenshot above are replaced by the ? character.

The current version uses static variable to hold the executed SQL. If there is more than one user interacting with the application, this will lead to some synchronization problems. For example, you can extend the NHibernateSQLMonitor class to use the ASP.NET Session store. This way the user will see only the SQL code executed as a result of his actions.

P.S. This post was inspired long time ago after reading the Steve Sanderson’s Pro ASP.NET MVC Framework. He has a similar application that connects to Linq to SQL and displays the executed SQL.