Развертывание ASP.NET MVC 2 для IIS 7.5 с ориентацией на .NET 3.5

Question

Я создал приложение ASP.NET MVC 2 в Visual Studio 2008. Я настроил сборку выпуска так, чтобы она проходила через компилятор ASP.NET для предварительной компиляции всех представлений, минимизации Javascript и CSS, очистки web.config и т. Д.Поскольку производственное развертывание направляется на сервер IIS6, я настроил псевдопроизводственное развертывание на компьютере под управлением Windows 7, чтобы пул приложений запускался в классическом режиме, ориентированном на среду выполнения 2.0.Я установил обработчик без расширений в web.config, который необходим, и все работает отлично.

Проблема возникла, когда я обновил решение до Visual Studio 2010. Я все еще нацеливаюсь на структуру 3.5 , но теперь я использую MSBuild 4.0, поскольку именно это использует Visual Studio 2010.Все по-прежнему компилируется правильно, потому что он работает нормально под Cassini, но когда я развертываю его в том же месте (тот же пул приложений, идентификация и т. Д.), Он теперь ведет себя по-разному.У меня все еще есть обработчик без расширений в web.config, но теперь, когда я перехожу к корню приложения, он просматривает каталог, и все маршруты, которые он ранее обрабатывал, теперь возвращаются как ошибки 404, обрабатываемые обработчиком StaticFile в IIS.,Я в растерянности из-за того, что изменилось и вызывает разрыв.

Я посмотрел на этот вопрос , но я уже убедился, что все необходимые компоненты установлены.

Answer 1

Вы пытались отлаживать свои маршруты, используя Phil Haack отладчик маршрутов на сервере?

Edit:
В IIS 7.5 вам не нужен какой-либо специальный обработчик без расширений, он обрабатывается автоматически, вам не нужно ничего менять. Это необходимо только на IIS 6, насколько я знаю. Может ли это быть проблема? что если вы удалите этот специальный обработчик? возможно это - то, что останавливает это, чтобы пнуть в двигателе маршрута.

Edit:
Я дважды проверил, и, как я думал, начиная с IIS7, режим по умолчанию для домена приложения - Интегрированный режим . Это означает, что стек Asp.net включается при каждом запросе, тогда как в классическом режиме asp.net вызывается только при вызове определенных расширений (aspx ashx axd по умолчанию сопоставляется с фильтром aspnet_isapi).
UrlRoutingModule включается при каждом запросе, ничего от вас не требуя, потому что это HttpModule, а не Handler. (он просто должен быть зарегистрирован в файле конфигурации вашего приложения, нет необходимости сопоставлять его с расширением, но это по умолчанию в приложении MVC. Вы можете открыть свой файл Web.Config и убедиться, что у вас есть под узел

<modules runAllManagedModulesForAllRequests ="true">
...
<add name="UrlRoutingModule" type=.../>
</modules>

Вы уверены, что развернули сборки MVC на сервере? Убедитесь, что для ссылок System.Web.Mvc , System.Web.Routing и System.Web.Abstraction для свойства Copy Local установлено значение true, чтобы убедиться, что использовать одни и те же сборки локально и на рабочем сервере ...

Если все это правильно, я не знаю, как вам помочь больше ... Надеюсь, это поможет вам или, по крайней мере, поставит вас на правильный путь.

EDIT: Оу ... просто прочитайте ваш последний комментарий ... извините, я пропустил этот элемент в классическом режиме. Ваш заголовок упоминает IIS7.5, и я предполагал слишком много вещей. вот почему я запутался.

Честно говоря, мне пришлось заглянуть в книгу Стивена Сандерсона. У него есть контрольный список для устранения неполадок развертывания IIS6. Я знаю, что вы говорите, что только при использовании MSBuild 4 происходит сбой, но он все еще может быть полезным

Убедитесь, что Default.aspx установлен как страница содержимого по умолчанию. Это может быть источником 404.

Затем, чтобы иметь URL без расширений, в прошлый раз, когда я развернул на IIS6, я использовал простую карту подстановки, и у меня никогда не было проблем ... Если вы все еще в беде, извините, что я не могу помочь ... не то чтобы я не пытался :) удачи

Answer 2

Я столкнулся с этой проблемой сегодня, в похожем сценарии.

Проблема в моем случае была связана с тем, что вместо 64 бит было зарегистрировано 32 бита asp, что вызвало проблему с маршрутизацией.

Чтобы решить эту проблему, введите в командной строке следующее:

CD c:\windows\microsoft.net\framework64\v4.0.30319
aspnet_regiis -i

Answer 3

Я уже разместил это решение в другой ветке, но я повторюсь.Используйте классический конвейерный режим AppPool:

альтернативный текст http://img823.imageshack.us/img823/3684/20100612135212.png

Также не забудьте установить HTTP Redirection модуль в Включение или отключение функций Windows .

Answer 4

Пара идей, чтобы попробовать

• Проводили ли вы какие-либо сравнения? между выходом VS2008 и Проекты VS2010? Просто проверяя, что обновление решения не изменилось что-нибудь.
• У вас есть web.config Атрибут targetFramework установлен на компиляция элемент?
• Вы уверены, что не бежите? во что-то вроде запуска приложения x86 в пуле приложений x64?

Полагаю, у вас все в порядке, но, поскольку у Кассини нет проблем с приложением, я все еще склоняюсь к проблемам web.config. Ваши модули / обработчики правильно зарегистрированы в элементе? Поскольку вы работаете в классическом режиме, вам понадобится и «старый», и «новый» ( ссылка 1 , ссылка 2 ).