Маршрутизация запросов, заканчивающихся на ".cshtml", к контроллеру - PullRequest
4 голосов
/ 27 августа 2011

(это кросс-пост к формам ASP.NET)

Я работаю над проектом WebGit .NET , и мы близки к выпуску "1.0". Однако у меня возникли проблемы с получением моего контроллера «Обзор» (который извлекает файлы из хранилища) для обслуживания файлов «.cshtml».

У меня изначально были проблемы с файлами ".config" и ".cs", но я исправил это в файле web.config:

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

Маршрутизация, которая должна обрабатывать этот запрос (который успешно маршрутизирует все остальное):

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

Теперь, когда я пытаюсь получить доступ к URL-адресу, оканчивающемуся на «.cshtml», он выдает 404, хотя мой запрос должен был обрабатываться контроллером «Обзор». Файлы, которые я обслуживаю, не существуют на диске, а вместо этого извлекаются из репозитория git в виде больших двоичных объектов. Любое другое расширение файла, которое я пробовал, прекрасно работает.

Как я могу исправить это поведение?

<ч /> РЕДАКТИРОВАТЬ: Я пытался отключить веб-страницы, например, так:

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

Но это, похоже, не имеет никакого эффекта.

Ответы [ 2 ]

6 голосов
/ 03 сентября 2011

В качестве быстрого обходного пути вы можете поместить временный файл browse.cshtml в корень приложения и поместить его в ваш файл web.config, добавив ключ = "webpages: Enabled" value = "false"

4 голосов
/ 31 августа 2011

Это известная ошибка в веб-страницах ASP.NET, которая неявно загружается при использовании MVC 3. Я не думаю, что существует простой способ отключить это поведение. Единственный обходной путь - использовать другое расширение (в частности, то, которое не указано в списке WebPageHttpHandler.GetRegisteredExtensions () )

Однако это будет исправлено в MVC 4. Приносим извинения за неудобства.

...