Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

UrlRewritingNet.UrlRewrite na nowych wersjach IIS

Wszytko idzie do przodu. Nowe wersje Windows Server, kolejne wydania IIS, co chwila udoskonalany framework .NET... świat IT leci do przodu jak oszalały. Kolejne reklamy promujące śweżynki, czy to w postaci oprogramowania lub sprzętu. Każdy musi mieć najnowszą wersję, najbardziej wypasiony sprzęt. Niestety w szarej rzeczywistości IT nieraz jesteśmy zmuszani do tego, aby działać ze starszym oprogramowaniem. Często dawno napisane aplikacje już nie sposób jest przepisać na nowy framework. Powody mogą być różne. Użycie zewnętrznych bibliotek, które już nie są wspierane, współpraca z innym starszym oprogramowaniem, zastosowanie składni/poleceń, które już zostały usunięte w nowych wersjach frameworka, czy po prostu brak czasu/zasobów na przeniesienie kodu do nowej wersji i ponowne testy.

Mam kontakt z oprogramowaniem, które również nie można przenieść na nowe wersje frameworku ze względu na kilka mniejszych i większych zależności, które wymieniłem. Nie ma już to większego znaczenia. W czym jednak jest problem? Otóż pewien projekt w czystym ASP.NET 3.5 (w sumie to 2.0) korzysta z biblioteki UrlRewritingNet.UrlRewrite (nie jest ważne dlaczego ktoś to użył i nie ma możliwości zmiany, zapewne wielu z Was ma również styczność z tego typu projektami). Jest to projekt, który pozwala na starszych wersjach ASP.NET korzystać z tzw. przyjaznych linków np. zamiastadres/Details.aspx?id=123&param=abcmożna użyć:
adres/Produkt/123/abc.
Często używany przez SEO itp. Niestety, nie można go już w realnym czasie przepisać na MVC, czy coś podobnego. Użycie UrlRewritingNet.UrlRewrite sprawiło, że wystawiając go na serwerze z nowym IIS, trzeba się pomęczyć, aby wszystko działało jak należy.

Przestawię mały poradnik jak zmusić UrlRewritingNet.UrlRewrite do działania na nowym IIS. Oto wymagane kroki:

  • przechodzimy na witrynę w IIS Manager na jakiej chcemy zmienić ustawienia
  • przechodzimy do Mapowania obsługi
  • edytujemy wpis StaticFile

    • zmieniamy w nim Ścieżkę żądania na :*.*
    • otwieramy Ograniczenie żądań i na zakładce Mapowanie zaznaczamy
    • Plik
    • zatwierdzamy podwójnie wybór

  • będąc w opcjach Mapowania obsługi dodajemy (menu po prawej) mapę skryptu

    • ścieżka żądania: *
    • wykonywalny: %windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
    • nazwa: Wildcard
    • otwieramy ograniczenie żądań i na zakładce Mapowanie odznaczamy checkboxa "Wywołaj obsługę tylko, jeśli...."
    • zatwierdzamy podwójnie, na pytanie o ISAPI odpowiadamy twierdząco

  • będąc w opcjach Mapowania obsługi dodajemy (menu po prawej) mapę skryptu

    • ścieżka żądania: *.html
    • wykonywalny: %windir%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll
    • nazwa: HTML VIRTUAL
    • otwieramy ograniczenie zadań i na zakładce Mapowanie odznaczamy checkboxa Wywołaj obsługę tylko, jeśli....
    • w tym samym oknie na zakładce Zlecenia zaznaczmy Jedno z następujących zleceń i wpisujemy: GET,HEAD,POST,DEBUG
    • zatwierdzamy podwójnie, na pytanie o ISAPI odpowiadamy twierdząco

  • będąc w opcjach Mapowania obsługi zaznaczmy (w menu po prawej) opcję Wyświetl listę uporządkowaną

    • za pomocą opcji Przenieś w dól/górę przenosimy Wildcard tak, aby znajdował się pod StaticFile
    • przenosimy HTML VIRTUAL tak, aby znajdował się pod ASPClassic

  • w drzewku po lewej zaznaczamy naszą witrynę i w menu po prawej zaznaczamy Ustawienia zaawansowane

    • w opcji Pula aplikacji wybieramy Classic .NET AppPool

Od tej pory dana aplikacja z UrlRewritingNet.UrlRewrite powinna bez problemów chodzić na nowych wersjach IIS. Jestem świadom, iż powyższa metoda ma zarówno plusy, jak i minusy. Jednakże całość funkcjonuje świetnie i nie ma problemów z działaniem. Mam nadzieję, że wpis będzie pomocny w rozwiązywaniu tego typu problemów lub podobnych. 

oprogramowanie porady serwery

Komentarze

0 nowych
tfl   8 #1 30.01.2013 17:05

W tym przypadku musze obiektywnie powiedziec, ze mod_rewrite jest o wiele bardziej przewidywalny i...hmm.. oczywistszy. No i zazwyczaj mam kontakt z aplikacjami, ktorych frontend stoi albo na apache, albo na nginix.

Swoja droga... coraz bardziej specjalistyczne blogi pojawiaja sie dzieki Tobie na dp. gj!

Docent REDAKCJA  14 #2 30.01.2013 17:34

@tfl:

Porównywanie UrlRewritingNet do mod_rewrite jest chyba średnio trafione w tym momencie. Tak jak djfoxer wspomniał, UrlRewriting został stworzony dawno temu, gdy sam IIS jeszcze nie oferował funkcji przepisywania URLi. Teraz istnieje moduł Url Rewrite (http://www.iis.net/downloads/microsoft/url-rewrite) - jest to oficjalny moduł udostępniany przez Microsoft, który instaluje się dwoma klikami w Web Platform Installerze. Potem wystarczy regułki regexowe wyklikać w IIS Manager albo po prostu wpisać w web.config. Co ważne, pula aplikacji witryny korzystającej z tego modułu może w ogóle nie mieć włączonego ASP.NET (bo działa on na poziomie IISa, a nie tak jak UrlRewritingNet - na poziomie aplikacji) i nie trzeba nic grzebać w modułach/handlerach. URL Rewrite do IIS pozwala nie tylko na przepisywanie adresów, ale też np. na przekierowania 301 i inne nietypowe akcje ;)

Podsumowując: nikomu już nie polecam zabaw z UrlRewritingNet dla nowych projektów, jest to mechanizm przestarzały, chyba już nawet nierozwijany. Tego już po prostu się nie używa (o czym świadczy konieczność przestawienia puli w tryb Classic - tracimy ogromną cześć funkcjonalności IIS, cały wbudowany .NET).

tfl   8 #3 30.01.2013 18:46

@docent

Napisalem "w tym przypadku", czyli uzywania urlrewritingnet do tworzenia paramlinkow w opozycji do mod_rewrite. Ale dziekuje za wyczerpujacy wyklad :)

bachus   20 #4 30.01.2013 22:14

ojoj, w miarę możliwości hosta, to już bym chyba wolał dodać nową instancję serwera na Hyper-V, niż tak rozwalać IIS :> Jak już wspomniał Docent, to już chyba lepiej ogarnąć URL Rewrite ;-)

djfoxer   18 #5 30.01.2013 23:09

@tfl
Dzięki ;) Docent już wyczerpał temat, ale dodam, że UrlRewritingNet był stworzony z myślą o IIS6 (stąd ta pula klasyczna, a nie zintegrowana dostępna od IIS7). Projekt nie jest już rozwijany, ze względu na to, iż lepszy rewriting jest już dostępny z IIS7+ o którym pisał Docent. W nowych projektach oczywiście nie ma sensu, ale są takie projekty, które nie sposób ruszyć i muszą działać bez zmian.

@bachus
Jakie rozwalanie IIS? :) Pula klasyczna po coś jest w IIS. Wiadomo, że tworząc nowe projekty nawet się nie będzie zawracało tym głowy . Jednakże życie w IT pokazuje, że nie jest tak kolorowo i część staroci, które z przyczyn wymienionych we wpisie, nie ma możliwości zaktualizowania do nowej wersji. Nie ma wyjścia, a z tego co swego czasu szukałem, temat UrlRewritingNet na nowych wersjach IIS jest dość popularny.

Podobnie jak nieśmiertelna Java 1.2, która w większych firmach już chyba pozostanie na wieki ;)

Autor edytował komentarz.
Docent REDAKCJA  14 #6 31.01.2013 13:56

@tfl:

Ok, odebrałem to po prostu tak, że porównanie przestarzałego rozwiązania w IIS do obecnie wykorzystywanego modułu mod_rewrite w Apache jest nie fair i jako szanujący się fanboj ;) musiałem zainterweniować.