Жаль начинать знакомство с библиотеками с их проблем. Но все-же. Сегодня я расскажу о том, какие проблемы могут возникнуть, при развертывании ASP.NET MVC приложений на IIS 6 и ранних версиях. Все дело в том, что запуская и тестируя ваше приложение из студии, вы можете и не догадыватся о том, что ваше приложение не запустится на сервере. Собственно это и произошло со мной.

Все дело в маршрутизации.

По умолчанию, во всех примерах MVC вы найдете:

public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default",                                               Route name
"{controller}/{action}/{id}",  URL with parameters
new { controller = "Customer", action = "Index", id = "" }  // Parameter defaults
);
routes.MapRoute(
"DefaultTwoParameter",
"{controller}/{action}/{id}/{step}"
);
}

Что говорит классу маршрутизации об отсутствии расширений в ваших «файлах», которые запрашивает клиент. Все бы хорошо, но IIS определяет что и как надо запускать, кому и с чем нодо передовать управление именно по расширению. Так что после создания виртуальной директории будет прислан однозначный ответ 404.

Исправить это можно следушим способом:

public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("{resource}.axd/{*pathInfo}");
routes.MapRoute(
"Default",                                               Route name
"{controller}.mvc/{action}/{id}",  URL with parameters
new { controller = "Customer", action = "Index", id = "" }  // Parameter defaults
);
routes.MapRoute(
"DefaultTwoParameter",
"{controller}.mvc/{action}/{id}/{step}"
);
}

После чего в конфигурации виртуальной директории добавить это расширение (.mvc) с тем-же обработчиком, что и у .aspx: aspnet_isapi.dll.
Настало время вспомнить, если ли места где исползуются жестко закодированные ссылки. Если таковые есть, то перечитайте заново про хелперы, которые используются в MVC.