Routing requests that end in “.cshtml” to a contro

(This is cross-posted to the ASP.NET forms)

I'm working on the WebGit .NET project, and we are close to a "1.0" release. However, I'm having trouble getting my "Browse" controller (which pulls files out of the repository) to serve-up ".cshtml" files.

I originally had trouble with ".config" and ".cs" files as well, but I fixed that with this in the web.config:

  <location path="browse">
    <system.webServer>
      <security>
        <requestFiltering>
          <fileExtensions allowUnlisted="true">
            <clear />
          </fileExtensions>
          <hiddenSegments>
            <clear />
          </hiddenSegments>
        </requestFiltering>
      </security>
    </system.webServer>
  </location>

The routing that should be handling this request (that is successfully routing everything else) is:

routes.MapRoute(
    "View Blob",
    "browse/{repo}/blob/{object}/{*path}",
    new { controller = "Browse", action = "ViewBlob", path = UrlParameter.Optional });

Now, whenever I try to access a URL that ends in ".cshtml", it gives a 404, even though my request should have been handled by the "Browse" controller. The files I'm serving-up do not exist on disk, but are instead pulled from a git repository as blobs. Every other file extension that I have tried works just fine.

How can I fix this behavior?

EDIT: I have tried disabling WebPages like so:

<appSettings>
  <add key="webpages:Enabled" value="false" />
</appSettings>

But that appears to have no effect.

回答1:

As a quick workaround, you can put a temporary browse.cshtml file at your application root and put this inside your web.config, add key="webpages:Enabled" value="false"

回答2:

This is a known bug in ASP.NET WebPages, which gets implicitly loaded when you are using MVC 3. I don't think there is a straightforward way of disabling this behavior. The only workaround is to use a different extension (specifically, one that is not listed via WebPageHttpHandler.GetRegisteredExtensions())

This will be fixed in MVC 4, however. Sorry for the inconvenience.