sobota, 16 maja 2009

ASP.NET MVC oraz IIS 6

Hostowanie aplikacji utworzonej za pomocą frameworka ASP.NET MVC na serwerze IIS 6 jest niestety bardzo problematyczne. Utworzone w ten sposób aplikacje wyświetlają niemiły (i w tym przypadku niezrozumiały) komunikat: 404 Not Found. Dlaczego tak się dzieje?

Żądania przychodzące do serwera są przetwarzane poprzez odpowiednie filtry ISAPI (pomijam dla uproszczenia inne zachodzace tam procesy), zgodnie z mapowaniem odpowiednich rozszerzeń. I tak na przykład .ASPX trafia do filtra aspnet_isapi.dll. Routing ASP.NET MVC wymaga użycia modułu IHTTPModule i wywołania UrlRoutingModule. Niestety to wymaga przejścia przez wymieniony wcześniej filtr aspnet_isapi.dll - a ten domyślnie nie jest w tym przypadku żądany, a serwer wyświetla nam błąd 404.

Ok, jak wyjść z opresji?

Metoda 1: Prosta

Odrazu ostrzegam: ta metoda nie nadaje się do zastosowania w dużych, obciążonych witrynach. Zaraz okaże się dlaczego.

Rozwiązanie to opiera się o wildcard. Polega to na tym, że wszystkie żądania przychodzące do serwera będą puszczane przez aspnet_isapi.dll. Zaletą jest prostota, wadą: każde żądanie: nawet o obrazek, plik .css, plik multimedialny i każdy inny plik będzie wiązał się przejściem przez handler DefaultHttpHandler/StaticFileHandler. Takie rozwiązanie oznacza brak cachowania żądań oraz kompresji. Marnotrawstwo zasobów serwera, a to dla mocno obciążonych maszyn oznacza problemy.

Ok, ale dla developerskich zastosowań takie rozwiązanie będzie wystarczające, więc zaczynamy konfigurację:

1. Otwieramy przystawkę Internetowe Uslugi Informacyjne i klikamy właściwości naszej aplikacji MVC.

2. Przechodzimy na kartę: Katalog macierzysty oraz klikamy przycisk Konfiguracja

screen_02 2009.05.16 20.02


3. Klikamy przycisk Insert, wpisujemy rozszerzenie: .mvc potem lokalizację: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll oraz odznaczamy opcję Sprawdz, czy plik istnieje.

Metoda 2: Zmiana ścieżki routingu

Metoda ta polega na dodaniu rozszerzenia .aspx po nazwie kontrolera, czyli stworzenia ścieżki routingu w ten deseń: {controller}.aspx/{action}/{id}

Niestety tracimy nasze czyste ścieżki, które zapewniało nam MVC.

 

Metoda 3: URL Rewriting

Ta metoda to nic innego jak zautomatyzowanie metody drugiej (odpada nam zmiana ścieżek). Musimy skonfigurować przepisywanie ścieżek tak, aby moduł dopisał znane ASP.NET rozszerzenie i przepuscił je przez odpowiedni filtr.

3 komentarze:

dario-g pisze...

Aktualnie wykorzystuję w projektach komercyjnych (nawet tych mocno obciążonych) właśnie metodę mapowania wildcard. Przyczym wszelkie żądania o pliki statyczne przepuszczam przez dedykowany moduł, który właśnie robi wszystko to czego nie wykonuje DefaultHttpHandler/StaticFileHandler. Na dodatek robi więcej, bo kompresuje (usuwa niepotrzebne linie) oraz łączy w jeden plik (js, css), itp.

Poza tym o tą metodę jest łatwo poprosić firmę hostingową, która włącza mapowanie bez żadnych przeszkód. Przynajmniej tam, gdzie ja mam swoje konta :)

King@Work pisze...

Zgadzam się z dario-g. Nie wiem czy wiesz Darku ale właśnie w rozwiązaniu, które u nas było zastosowane (w poprzedniej firmie) - była wykorzystana metoda wildcard (jako że mieliśmy hosting na iis 6). A dopiero IIS 7 umożliwia ładne hostowanie aplikacji MVC

Dopisaliśmy tylko handlery dla css-ów , js-ów (minimalizujące) no i StaticFileHandler - który wszystkie statyczne pliki kompresował GZIP-em i ustawiał odpowiednie nagłówki cachowania.

Czasem nawet IIS źle to robi, a tak masz pełną kontrolę.

Proponuję abyś poczytał wpis na blogu niejakiego Omar Al Zabir - on jest autorem rozwiązanie o nazwie FastMVC - umożliwiającym lepszy hosting aplikacji MVC na IIS6
http://msmvps.com/blogs/omar/archive/2008/06/30/deploy-asp-net-mvc-on-iis-6-solve-404-compression-and-performance-problems.aspxPozdrawiam Krzysztof Król

Dariusz Tarczyński pisze...

@dario-g & @King@Work

Tak, zgadzam się z wami w 100%, że takie mieszane rozwiązanie nie jest złe. Złe jest właśnie niezastosowanie takiego mapowania. Szczerze mówiąc to w następnej notce chciałem przedstawić taki własny handler :-)

@King@Work
Dzięki za linka do FastMVC,przyjrzę się temu projektowi.