Чтобы уточнить, сценарии я, глядя на включают развертывание ASP.NET 4 Web Forms приложения, которые используют RouteTable.Routes.MapPageRoute:Развертывание ASP.NET 4 Web Forms приложений с помощью маршрутизации на IIS 6
public class Global : System.Web.HttpApplication
{
public static void RegisterRoutes(RouteCollection routes)
{
RouteTable.Routes.MapPageRoute("questionnaires", "questionnaires", "~/Pages/Questionnaires/List.aspx", false);
RouteTable.Routes.MapPageRoute("questionnaires_submit", "questionnaires/submit", "~/Pages/Questionnaires/Insert.aspx", false);
}
void Application_Start(object sender, EventArgs e)
{
RegisterRoutes(RouteTable.Routes);
}
}
Сценарий 1: Приложение НЕ размещено как виртуальный каталог на существующем веб-сайте, а является автономным веб-сайтом (это его собственная отправная точка). Он имеет собственный пул приложений. При развертывании он работал без какого-либо вмешательства.
Сценарий 2: Приложение размещено как виртуальный каталог под существующим веб-сайтом. Он также имеет собственный пул приложений. Однако, Я получил 404 ошибки при попытке доступа к маршрутам, которые я наметил. К счастью, у меня был опыт получения MVC для работы в 3.5 sp 1, поэтому я попробовал этот метод: открыл диалоговое окно свойств виртуального директора, перешел на вкладку «Каталог», нажал кнопку «Конфигурация» и добавил карту приложений подстановочного знака к aspnet_isapi.dll и не установлен флажок «Проверить, что файл существует». Это заставило его работать.
Мой вопрос, почему я должен добавить карту приложения подстановочного знака во втором сценарии, но не в первую очередь? Если это помогает, корневой веб-сайт, на котором размещается виртуальный каталог во втором сценарии, настроен с помощью ASP.NET версии 2.0.50727.
Я ценю вашу помощь, и эта статья проницательна, но она по-прежнему не уточняет (для меня), почему маршрутизация обрабатывается по-разному для виртуального каталога, работающего под управлением версии 4 (внутри веб-сайта для запуска 2) и веб-сайта запущенная версия 4. – Merritt
Я бы предположил, что URL-адреса, расширения и т. д. в основном контролируются на корневом уровне. Таким образом, корневая конфигурация (.NET 2.0) вызывается сначала, поскольку IIS должен даже знать, к какому виртуальному каталогу следует отправить запрос. Запрос -> IIS -> Виртуальный сайт (.NET 2 обрабатывает обработчик/маршрутизацию файлов здесь) -> Виртуальный каталог (.NET 4 обрабатывает координированный код). Else request -> IIS -> Vitural Site (управляемый код и обработчик/маршрутизация .NET 4 hanldes) – Tommy