Razor ASP.NET web pages and CSHTML Forbidden errors

Recently, we had a support request come through for Cytanium’s ASP.NET 4.5 beta from a user trying to access an app written for ASP.NET web pages with Razor syntax. After publishing the files, the user was receiving the following YSOD:

Server Error in ‘/’ Application.


This type of page is not served.

Description: The type of page you have requested is not served because it has been explicitly forbidden. The extension ‘.cshtml’ may be incorrect. Please review the URL below and make sure that it is spelled correctly.
Requested URL: /testpage.cshtml

Normally, this is indicative of incorrect Application Pool settings. Razor syntax only works with ASP.NET 4.0 and requires the Integrated Pipeline to function properly. However, you also need to appropriate ASP.NET MVC files on the server – either in the GAC or deployed to your local /bin folder. Most people have ASP.NET MVC GAC’d on their development systems, so the application will work locally without having the appropriate DLL’s in the /bin folder of the web application. But that’s not necessarily the case on the server side. Per Microsoft’s recommendation, ASP.NET MVC is not GAC’d on the servers as there could be version issues that have a wide impact on all sites running on a shared host. Rather, it is recommended to bin deploy ASP.NET MVC DLL’s to each site. Once the appropriate DLL’s are in the /bin folder, and the app is running under ASP.NET 4.0 Integrate Pipeline, IIS will serve files written with Razor syntax.

ASP.NET Routing and IIS 404 errors

ASP.NET Routing is a powerful feature introduced in .NET 3.5 SP1 and included with .NET 4.0 that allows a developer to route URL’s that are not real files. There are several ways you can accomplish this same task, but having it in the ASP.NET pipeline allows the developer great flexibility in how URL’s are routed. However, it does not always work “out-of-the-box” for devs. The most common error I’ve seen is a 404 error – meaning the page cannot be found.

There can be several contributing factors. If you are attempting to utilize extenionless URL’s, ensure you have the appropriate IIS hotfix installed: http://support.microsoft.com/kb/980368. More commonly however, the issue is a result of the module not firing for your request type. The easy fix is to add runAllManagedModulesForAllRequests=true to the modules tag in your web.config. However, that could have performance implications as you are now telling IIS to ignore the preCondition setting for all modules. The alternative solution is to remove the managedHandler preCondition for the URLRouting module:

 <modules>
 <removename=“UrlRoutingModule“ />
 <addname=“UrlRoutingModule“type=“System.Web.Routing.UrlRoutingModule“ preCondition=“”/>
 </modules>