This article is taken from the book ASP.NET MVC 2 in Action. The authors discuss URL rewriting as a powerful deployment option that opens up new scenarios in URL canonicalization and seamless resource management.
When we deploy our MVC application to
Internet Information Services (IIS) 6 and earlier, we can consider a
few options concerning routes. IIS 6 and earlier use Internet Server
Application Programming Interface (ISAPI) filters, which map file
extension requests to ISAPI handlers. Extensions, such as .aspx and
.ascx, map to the ASP.NET ISAPI handler, but extensions in the pretty,
extension-less MVC URLs do not. By the time ASP.NET handles the
request, IIS has already chosen an ISAPI handler for the request, and
the selection may not be ASP.NET. Unfortunately, developing custom
ISAPI filters requires C/C++ knowledge. Although some open source
projects exist for writing managed ISAPI filters, it is not as easy as
creating a custom IHttpHandler or IHttpModule implementation.
Out of the box, ASP.NET MVC applications will not work in IIS 6.
Getting an MVC application to run successfully in an IIS 6 environment
requires either changes to our routes or extra configuration steps in
IIS. Our four choices for deploying to IIS 6 are:
Configure routes to use the .aspx extension
Configure routes to use a custom extension (such as .mvc)
Use a wildcard mapping with selective disabling
Use URL rewriting
Instead of mapping our routes to the .aspx extension, a custom
extension could reduce the confusion of users accustomed to Web Forms
URLs. We’ll configure our routes to use the .mvc extension instead of
.aspx, as seen in listing 1.
This configuration differs from the previous .aspx route configuration
in the extension only. When it comes to deploying this route
configuration, we need to perform additional steps in IIS. Since IIS is
not configured to handle requests from the .mvc extension, we’ll need
to add a mapping that will enable the ASP.NET ISAPI filter to handle
the .mvc extension. To map the new extension, follow the listed steps
as shown in figures 1 and 2:
1. Create the website with the default configuration.
2. In the Home Directory tab in the Properties dialog for the website, click Configuration.
Figure 1 Website properties dialog
3. In the Mappings tab in the Application Configuration dialog, click Add….
4. In the Add/Edit Application Extension Mapping dialog, set the
Executable value to the path to the aspnet_isapi.dll. This is typically
at C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll. Use
the .NET 2.0 version of the dll.
5. Set the Extension value to .mvc. Make sure the extension has the leading dot.
6. Select All verbs in the Verbs section. If you know the HTTP verbs
you wish to support, provide a commaseparated list of the verbs in the
Limit to section.
7. Uncheck the Verify that file exists option. The requested URLs will
not map to a location on disk, and IIS responds with a 404 if you don’t
uncheck this value.
8. Click OK on all of the configuration dialogs.
Now that we have configured IIS to allow ASP.NET to handle requests for
the .mvc extension, we can use the MVC application. Our new URL is
http://localhost:82/product.mvc/show/4, which is only a slight cosmetic
change from http://localhost:81/product.aspx/show/4—the original
With the new routing abilities of ASP.NET MVC, came new deployment
challenges. Although IIS 7 supports extension-less, pretty URLs out of
the box, earlier versions of IIS do not. However, we have a variety of
deployment options with earlier versions of IIS, some of which enable
pretty URLs. URL rewriting is the most powerful of these deployment
options because it opens up new scenarios in URL canonicalization and
seamless resource management.
For Source Code, Sample Chapters, the Author Forum and other resources, go to