Получение ошибки 404.0 для приложения ASP.NET MVC 3 на IIS 7.0/Windows Server 2008
Я пытаюсь развернуть приложение ASP.NET MVC 3 на сервер x64 для Windows 2008 (очевидно, работает с IIS 7.0), и IIS не хочет правильно обслуживать контент. Все запросы приводят к ошибке 404.0, потому что запросы не соответствуют любому обработчику, и IIS пытается использовать обработчик StaticFile для обслуживания запросов. Проблема, похоже, связана с .NET 4.0, так как приложение MVC 2 работает отлично в пуле приложений, настроенном на среду выполнения .NET 2.0.
У меня не было проблем с развертыванием этого же приложения на серверах IIS 7.5 как на Windows 7, так и на Windows Server 2008 R2.
До развертывания на сервере 2008 года не было установлен .NET 4.0 или ASP.NET MVC 3, поэтому вот шаги, которые я предпринял до развертывания приложения:
- Установленный .NET 4.0
- Ran aspnet_regiis.exe(из папки Framework64/v4.0.30319)
- Установленный ASP.NET MVC 3 с помощью установщика веб-платформы
- Прикладное обновление MS KB980368, чтобы включить определенные обработчики IIS 7.0 или IIS 7.5 для обработки запросов, URL-адреса которых не заканчиваются период
Запросы к статическим ресурсам в приложении (файлы JavaScript, изображения и т.д.) проходят без сбоев, но любой запрос на действие MVC не выполняется с ошибкой 404.0. Я заметил, что IIS использует обработчик StaticFile для обработки этих запросов, что явно неверно. Обработчики ASP.NET 4.0 (т.е. Обработчики ExtensionlessUrl-ISAPI-4.0 *) правильно определены, насколько я могу судить, поэтому я понятия не имею, почему/как запрос не будет обрабатываться одним из этих обработчиков и упадет все путь вниз к обработчику StaticFile.
Я также наткнулся на следующую статью базы знаний MS, в которой упоминается, что вы должны убедиться, что перенаправление HTTP и статическое сжатие содержимого включены/установлены на сервер, на котором вы столкнулись с ошибками 404. Я проверил, и обе функции уже были включены для моего сервера. Я даже попытался удалить и переустановить функции безрезультатно.
В этот момент я совершенно не понимаю, почему это работает неправильно. Я смог реплицировать проблему на двух разных серверах IIS 7.0. Что мне не хватает?
Ответы
Ответ 1
Проблема закончилась тем, что мой код полностью полагался на функцию автоматического запуска, доступную только в IIS 7.5. Мне удалось обнаружить проблему с помощью функции отслеживания неудачных запросов в IIS, и теперь я изменил свой файл global.asax.cs, чтобы приложение было правильно инициализировано независимо от того, как оно загружается.
Ответ 2
Вы на самом деле просто напомнили мне, что мне нужно решить эту проблему в окружении. Если ваша ситуация такая же, как у меня, то это простое решение.
Просто добавьте в свою веб-конфигурацию следующее:
<system.webServer>
<modules runAllManagedModulesForAllRequests="true" />
Изменить. Чтобы предоставить дополнительные пояснения по проблеме. В моем случае, когда я добавлял пользовательские сопоставления маршрутов, IIS рассматривал запросы как запросы папки/статического файла и, таким образом, пропускал рабочий процесс ASP.NET. Это ведет себя по-разному в среде разработки, поскольку она выполняется под веб-сервером разработки, который также будет передавать все запросы через процесс .net.
В этой записи Web Config указано, что у вас есть модули, которые должны запускаться на каждом веб-запросе, даже если IIS определяет его как статический файл или папку.
Ответ 3
Пожалуйста, убедитесь, что вы работаете в режиме IIS 7.0 Integrated. Если вам нужно запустить его в режиме IIS 7.0 Classic, вам нужно выполнить несколько действий, чтобы заставить маршруты работать. Пожалуйста, напишите следующие сообщения в блоге;
http://www.tugberkugurlu.com/archive/running-asp-net-mvc-under-iis-6-0-and-iis-7-0-classic-mode---solution-to-routing-problem
http://www.tugberkugurlu.com/archive/deployment-of-asp-net-mvc-3-rc-2-application-on-a-shared-hosting-environment-without-begging-the-hosting-company
Ответ 4
Мое решение, попробовав ВСЕ:
Плохое развертывание, старый PrecompiledApp.config висел вокруг моего местоположения развертывания и делал все неработоспособным.
Мои последние настройки, которые работали:
- IIS 7.5, Win2k8r2 x64,
- Пул приложений с интегрированным режимом
-
В web.config ничего не меняется - это означает отсутствие специальных обработчиков для маршрутизации. Здесь мой снимок разделов содержит много других сообщений. Я использую FluorineFX, поэтому у меня есть этот обработчик, но мне не нужны другие:
<system.web>
<compilation debug="true" targetFramework="4.0" />
<authentication mode="None"/>
<pages validateRequest="false" controlRenderingCompatibilityVersion="3.5" clientIDMode="AutoID"/>
<httpRuntime requestPathInvalidCharacters=""/>
<httpModules>
<add name="FluorineGateway" type="FluorineFx.FluorineGateway, FluorineFx"/>
</httpModules>
</system.web>
<system.webServer>
<!-- Modules for IIS 7.0 Integrated mode -->
<modules>
<add name="FluorineGateway" type="FluorineFx.FluorineGateway, FluorineFx" />
</modules>
<!-- Disable detection of IIS 6.0 / Classic mode ASP.NET configuration -->
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
-
Global.ashx: (только метод любой заметки)
void Application_Start(object sender, EventArgs e) {
// Register routes...
System.Web.Routing.Route echoRoute = new System.Web.Routing.Route(
"{*message}",
//the default value for the message
new System.Web.Routing.RouteValueDictionary() { { "message", "" } },
//any regular expression restrictions (i.e. @"[^\d].{4,}" means "does not start with number, at least 4 chars
new System.Web.Routing.RouteValueDictionary() { { "message", @"[^\d].{4,}" } },
new TestRoute.Handlers.PassthroughRouteHandler()
);
System.Web.Routing.RouteTable.Routes.Add(echoRoute);
}
-
PassthroughRouteHandler.cs - это обеспечило автоматическое преобразование из http://andrew.arace.info/stackoverflow в http://andrew.arace.info/#stackoverflow, который затем будет обрабатываться по умолчанию .aspx:
public class PassthroughRouteHandler : IRouteHandler {
public IHttpHandler GetHttpHandler(RequestContext requestContext) {
HttpContext.Current.Items["IncomingMessage"] = requestContext.RouteData.Values["message"];
requestContext.HttpContext.Response.Redirect("#" + HttpContext.Current.Items["IncomingMessage"], true);
return null;
}
}
Ответ 5
Если вы используете веб-приложение в IIS 7.5 или выше, убедитесь, что службы роли для IIS включены должным образом. Ролевые сервисы, представляющие интерес: ASP.NET, базовая аутентификация, перенаправление HTTP, фильтры ISAPI и т.д.
Вы можете перейти к службам роли через "Добавить или удалить программы" - включить или выключить функции Windows.
Надеюсь, это поможет.
С уважением,
Киран Банда
Ответ 6
У меня была та же проблема. Шахта оказалась неудачной сборкой при запуске приложения. Я разрешил Fusion Log Viewer видеть, какие сборки были неудачными, и понял это. Я бы никогда не узнал об этом, так как это показалось мне проблемой маршрутизации MVC, но я решил, что опубликую это, если кто-нибудь еще потратит понапрасну на эту проблему!