Using System.Web.Routing with WebForms

A hidden gift in the ASP.NET MVC framework is the addition of more flexible routing into the ASP.NET world view. While it may first appear to be MVC-only, it’s in fact quite easy to bring it into old style “WebForms” ASP.NET projects.

Before ASP.NET MVC, that is in the land of WebForms, it was hard to produce nice URLs using ASP.NET. This was because routing within ASP.NET was based on one of two things:

• A simple mapping from URL to a physical folder structure on the web server, which produced ugly URLs, or;
• Engaging in URL-rewriting through IIS, which is complex and takes control of the URL structure away from where it really belongs with the web application.

ASP.NET MVC brought with it the divorce of URL from execution code familiar to Rails, Pylons and other recent web frameworks via the classes in the " System.Web.Routing namespace. It initially looked, however, like the Routing magic which MVC included was unavailable to old-school WebForms projects. After receiving some interest in routing from other teams inside Microsoft, however, the MVC team brought the Routing objects outside the MVC framework so that they can be used from within WebForms projects.

The classes in System.Web.Routing alter the way URLs are mapped to handling code. The Routing code expects to map a URL to executing code, and provides an interface IRouteHandler which can be implemented to supply your own over the default implementation. It’s actually quite simple to write a handler to map a URL to an .aspx page, but even so this has thankfully been done already —making using Routing even simpler. After adding the IRouteHandler, you just need to make a couple of changes to the web.config file to load the Routing machinery.

What makes swapping in System.Web.Routing so seamless is all Routing does is map a URL string to an executing page. This means the POST data used by WebForms to transport data from the browser to the server passes through the routing operation unaffected, so WebForms can carry on working without being informed of the change of routing policy—provided you are using WebForms standard “always POST” style.

If you are starting a new project, you can use the sample code and instructions at haacked directly because the sample code includes a skeleton ASP.NET WebForms project correctly configured to use Routing. From what I can tell, the code from haacked is provided as-is, but it seems to work in my testing but you should be sure to fully test in your environment!

To use Routing within an existing project you need to perform a few more steps, which I’ve stitched together from a few sources on the net. We can reuse some of the code from haacked, and MSDN provides a short howto for modifying your web.config appropriately.

Before starting, you need to download the .net 3.5 SP1 framework or above, as it contains the needed ASP.NET MVC and routing libraries.

1. First, download the sample code at haacked and copy the WebFormRouting project into your web application’s solution.
2. Add references to your web application project to System.Web.Routing and the WebFormRoutingproject you just added.
3. Copy the Application_Start() and RegisterRoutes() methods from the haacked sample project’s Global.asax from step one into the Global.asax file of your web application (create one if needed) and add the needed using statements. You can now close the haacked solution.
4. Follow these instructions at MSDN for the changes you need to make to your web.config file—you only need to follow the instructions under the heading “To configure an ASP.NET Web site project for routing” as the WebFormRouting project contains the IRouteHandler implementation.
5. Write some routes for your application—restart your application and you should be done!

If you want to access the Routing data from your application, change your aspx pages to inherit from RoutablePage from WebFormRouting rather than Page. The request parameters (contained within { and } in your routes) should now be available from your page in the RequestData.Values dictionary-like object. For example, if your route is /updates/{username} you can access the username via RequestData.Value["username"].

For more information on using routing once you have it plumbed in, there’s an the “main MSDN page”:“msdnrouting about Routing, which provides a great jumping off point for writing routes. If that’s not enough, a Google search for " System.Web.Routing":googlerouting currently produces a great wealth of further information on the subject.