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 extension.

Conclusion:

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
http://www.manning.com/palermo2/