Rozdział 18.
Konfiguracja i wdrażanie aplikacji ASP.NET

W poprzednich siedemnastu rozdziałach dowiedziałeś się jak tworzyć niemal wszystkie elementy aplikacji ASP.NET. Jednak nie dowiedziałeś się jeszcze jak można zarządzać całą aplikacją. Aplikacje tworzone w poprzednich rozdziałach książki składały się zazwyczaj z pojedynczych stron ASP.NET, które czasami wykorzystywały inne pliki. W tym rozdziale opiszę w jaki sposób można połączyć te wszystkie strony w jedną, spójną aplikację, w której wszystkie ustawienia i zdarzenia można kontrolować z jednego miejsca.

W ASP.NET szczególne znaczenie mają dwa pliki — global.asx oraz web.config. Pierwszy z nich kontroluje zdarzenia zachodzące w aplikacji. Korzystając z udostępnianych przez niego możliwości, można, przykładowo, wykonać określony kod w momencie obsługi pierwszego żądania skierowanego do którejkolwiek ze stron, lub za każdym razem gdy jest otrzymywane żądanie dotyczące określonej strony. Drugi z plików — web.config — zawiera ustawienia aplikacji, na przykład: ustawienia bezpieczeństwa lub informacje określające sposób działania sesji.

Pod koniec rozdziału przekonasz się, jak łatwo można wdrożyć aplikację ASP.NET i uruchomić ją na innym serwerze. Bardzo często programiści tworzą aplikacje na testowych serwerach, a dopiero po zakończeniu pracy i usunięciu błędów przenoszą je na serwery docelowe. ASP.NET sprawia, że proces ten stał się banalnie prosty.

W tym rozdziale zostaną omówione następujące zagadnienia:

·         Dokładna prezentacja aplikacji ASP.NET.

·         Czym są pliki global.asax oraz jak można się nimi posługiwać.

·         W jaki sposób można konfigurować aplikacje ASP.NET przy wykorzystaniu pliku web.config.

·         Jak korzystać z najczęściej stosowanych ustawień konfiguracyjnych.

·         Jak tworzyć własne ustawienia konfiguracyjne w aplikacjach ASP.NET.

·         W jaki sposób należy wdrażać aplikacje ASP.NET.

Prezentacja aplikacji ASP.NET

W poprzednich rozdziałach niniejszej książki poznałeś już niemal wszystkie zagadnienia związane z wykorzystaniem technologii ASP.NET, poczynając od sposobów tworzenia prostych formularzy internetowych, a kończąc na pisaniu i wykorzystaniu skomplikowanych obiektów biznesowych. Korzystając z tych komponentów możesz tworzyć strony ASP.NET o niezwykle potężnych możliwościach, zdolne do wykonywania niemal dowolnych operacji. Kolejnym krokiem jest scalenie tych wszystkich elementów w jedną, spójną aplikację, skonfigurowanie jej i wdrożenie.

Oczywiście można zebrać kilka stron ASP.NET i nazwać je aplikacją, jednak formalna definicja aplikacji jest nieco szersza. Według tej definicji aplikacja ASP.NET to: suma wszystkich plików, stron, procedur obsługi zdarzeń, modułów, kodu wykonywalnego (programów i bibliotek), wykonywanego lub uruchamianego w obrębie danego katalogu wirtualnego (i jego podkatalogów) na serwerze WWW. Całkiem rozbudowana definicja.

Być może przypominasz sobie, że katalog wirtualny jest katalogiem, który nie należy do drzewa katalogu głównego serwera WWW, choć klientom WWW wydaje się, że jest jego częścią. Na przykład, jeśli stosujesz domyślne ustawienia serwera IIS, to jednym z katalogów wirtualnych (a zarazem katalogiem głównym) jest c:\inetpub\wwwroot widoczny z poziomu Sieci jako http://localhost/. Innym katalogiem wirtualnym może być folder c:\moje\mojawitryna, widoczny jako http://localhost/mojawitryna. Fizycznie ten drugi folder nie znajduje się w katalogu głównym serwera, jednak żaden klient nie jest w stanie zauważyć jakiejkolwiek różnicy. Katalogi wirtualne można tworzyć w oknie Menadżera usług internetowych, a czynności jakie w tym celu należy wykonać nikomu nie przysporzą trudności (więcej informacji na ten temat znajdziesz w rozdziale 1., pt.: „Podstawy technologii ASP.NET”).

Podkatalogi katalogów wirtualnych mogą lecz wcale nie muszą być katalogami wirtualnymi. Typowa lista katalogów wirtualnych dostępnych na serwerze IIS działającym w systemie Windows 2000, została przedstawiona na rysunku 18.1.

Rysunek 18.1.              Typowy zestaw katalogów wirtualnych dostępnych na serwerze IIS 5.0 działającym w systemie Windows 2000, wyświetlony w Menadżerze usług internetowych

Każda aplikacja ASP.NET jest obsługiwana w odrębnej domenie aplikacji (patrz podrozdział „Przetwarzanie” w rozdziale 2., pt.: „Tworzenie stron ASP.NET”), co oznacza, że każda z nich może posiadać własne ustawienia konfiguracyjne. A zatem, jeśli na serwerze zostaną zdefiniowane dwa katalogi wirtualne — http://localhost/MyASP oraz http://localhost/MyASP/App2 — to drugi z nich będzie zupełnie niezależna aplikacją, która w żaden sposób nie wchodzi w skład pierwszej aplikacji.

Aplikacje ASP.NET są tworzone w momencie gdy serwer odbierze pierwsze żądanie dotyczące którejkolwiek ze stron tworzących tę aplikację (więcej informacji na ten temat znajdziesz w dalszej części rozdziału). Po utworzeniu aplikacji, można używać przeróżnych zdarzeń do kontrolowania sposobu wykonywania programu. Możliwości te są dostępne za pośrednictwem pliku global.asax, który zostanie szczegółowo omówiony w dalszej części rozdziału.

Folder \bin

Nowe wyrażenie

ASP.NET udostępnia nowy folder, który może być wykorzystywany w aplikacjach ASP.NET. Jest to folder \bin, nazywany także pamięcią podręczną komponentów .NET. Czytając rozdziały poświęcone tworzeniu i wykorzystaniu obiektów biznesowych dowiedziałeś się, że folder ten służy do przechowywania skompilowanych plików binarnych używanych w aplikacji (takich jak biblioteki DLL). Każda aplikacja posiada swoją własną pamięć podręczną komponentów .NET, jednak może także dziedziczyć pamięć podręczną komponentów po którejś z aplikacji nadrzędnych.

Folder \bin jest niezwykle ważny w aplikacjach ASP.NET. Stanowi on miejsce w którym można przechowywać obiekty wykorzystywane w aplikacji. Umieszczane w nim komponenty są automatycznie dostępne dla stron .aspx, dzięki czemu nie trzeba się przejmować skomplikowanymi ich tworzenia i ładowania. Więcej informacji na temat sposobów wykorzystania tego folderu znajdziesz w rozdziale 15, pt.: „Zastosowanie obiektów biznesowych”.

global.asax

Być może nigdy nie myślałeś o stronach ASP.NET jako o aplikacji. To całkiem zrozumiałe, gdyż strony te stanowią grupę luźno ze sobą powiązanych plików tekstowych. Tradycyjnie, za aplikację uważa się plik wykonywalny (.exe), ewentualnie wraz z towarzyszącymi mu plikami (takimi jak biblioteki DLL oraz pliki .ini). Aplikacje ASP.NET są zupełnie inne, gdyż użytkownicy mogą uruchomić dowolną stronę wchodzącą w ich skład (nie mają one bowiem żadnego ustalonego punktu startowego), a poza tym większość tworzących je plików jest zrozumiała dla ludzi.

W rzeczywistości, każdy katalog wirtualny na serwerze IIS jest aplikacją. Aplikacja taka jest uruchamiana w momencie otrzymania żądania dotyczącego którejkolwiek ze stron wchodzących w jej skład, niezależnie od tego która to będzie strona. Gdy użytkownicy przechodzą ze strony na stronę, przetwarzanie aplikacji dobywa się w tle, w sposób niewidoczny dla nich. Podobnie jak wszystkie tradycyjne aplikacje, także i aplikacje ASP.NET mogą przestać działać, można je także zatrzymać i uruchomić ponownie. Różnica polega jednak na tym, iż tradycyjne aplikacje są uruchamiane na komputerze użytkownika i prowadzą z nim bezpośrednią interakcję; natomiast aplikacje ASP.NET są uruchamiane na serwerze WWW a użytkownik może z nich korzystać wyłącznie za pośrednictwem przeglądarki.

Pamiętasz zapewne, że w środowisku .NET wszystko jest obiektem. Dotyczy to także aplikacji ASP.NET. Obiekt klasy HttpApplication dostarcza metod, właściwości i zdarzeń, tak samo jak strony ASP.NET i elementy sterujące serwera. Na tej podstawie można inaczej wyrazić informacje podane w poprzednim akapicie — gdy po raz pierwszy zostanie otrzymane żądanie dotyczące którejkolwiek ze stron należących do katalogu wirtualnego, tworzony jest nowy obiekt klasy HttpApplication.

Notatka
Należy zauważyć, iż aplikacja jest uruchamiana tylko w momencie otrzymania pierwszego żądania skierowanego do którejkolwiek ze stron znajdujących się w folderze wirtualnym. Nie oznacza to wcale, że jest ona uruchamiana w momencie otrzymania żądania do nowej strony. Przykładowo, jeśli aplikacja ASP.NET składa się z dwóch plików — default.aspx oraz exit.aspx — to zostanie ona uruchomiona w momencie otrzymania pierwszego żądania dotyczącego którejkolwiek z tych stron, a nie w momencie otrzymania pierwszego żądania skierowanego do  każdej z nich. Oznacza to, że aplikacja ASP.NET uruchamiana jest tylko raz. Gdyby prawdą było drugie stwierdzenie, oznaczałoby to, że aplikacje ASP.NET są uruchamiane za każdym razem gdy zostanie zażądana nowa strona.

Ale w jaki sposób można kontrolować obiekt HttpApplication (czyli, za jego pośrednictwem, zarządzać aplikacją ASP.NET)? Przetwarzanie każdej ze stron ASP.NET powoduje wykonanie pewnego zadania lub zadań, nie ma jednak wpływu na sposób działania aplikacji jako całości. Żadna strona ASP.NET nie może mieć bezpośredniego wpływu na sposób działania innej strony. Oznacza to, że musi istnieć pewien element centralny zarządzający wykonywaniem całej aplikacji — jest nim plik global.asax.

Plik global.asax nazywany jest plikiem aplikacji ASP.NET. Plik ten pozwala na tworzenie kodu wykorzystującego obiekt HttpApplication. Przy wykorzystaniu tego obiektu można kontrolować działanie aplikacji ASP.NET w taki sam sposób, w jaki używa się innych obiektów — posługując się ich metodami i zdarzeniami (w dalszej części rozdziału, gdy zdobędziesz już wszelkie niezbędne informacje dodatkowe, dowiesz się jak można to robić.)

Notatka
Należy wiedzieć, że wykorzystanie pliku global.asax jest całkowicie opcjonalne. Jeśli nie stworzysz tego pliku w swojej aplikacji, to będzie ona wykonywana w domyślny sposób, który całkowicie wystarcza, aby wszystko działało jak należy. Jeśli jednak będziesz chciał wykorzystać jakiekolwiek dodatkowe możliwości funkcjonalne, to będziesz musiał użyć pliku global.asax.

Plik global.asax jest umieszczany w głównym folderze aplikacji ASP.NET. Przykładowo, jeśli wykonywałeś przykłady przedstawiane w poprzednich rozdziałach, to zapewne utworzyłeś katalog wirtualny http://localhost/aspnetdlakazdego odpowiadający folderowi c:\inetpub\wwwroot\aspnetdlakazdego. Właśnie w tym folderze należy umieścić plik global.asax zarządzający działaniem aplikacji.

ASP.NET konfiguruje ten plik w taki sposób, aby nie można go było wyświetlić w przeglądarce. Dzięki temu, hakerzy nie mogą się włamać i zmodyfikować ustawień aplikacji. Jeśli ktoś wpisze w przeglądarce adres http://localhost/global.asax, zostanie wyświetlony komunikat o błędzie przedstawiony na rysunku 18.2.

Rysunek 18.2.              Próba wyświetlenia pliku global.asax w przeglądarce spowoduje zgłoszenie błędu.

Jak już wspominałem plik global.asax jest zarządzany przez środowisko .NET. Wirtualna maszyna CLR wykrywa każdą zmianę tego pliku i powoduje ponowne uruchomienie aplikacji, dzięki czemu uwzględniane są zmodyfikowane ustawienia. To ponowne uruchamianie aplikacji może być poważnym utrudnieniem dla korzystających z niej użytkowników i z tego względu plik global.asax należy modyfikować jak najrzadziej.

Klasa HttpApplication

Już wiesz, że aplikacje ASP.NET można kontrolować za pośrednictwem obiektu klasy HttpApplication, ale jaką rolę odgrywa w tym plik global.asax? W czasie działania aplikacji plik ten jest kompilowany do postaci dynamicznej klasy dziedziczącej po klasie HttpApplication. A zatem, za pośrednictwem pliku global.asax można uzyskać dostęp do obiektów i zdarzeń jego klasy bazowej, czyli klasy HttpApplication.

Podczas inicjalizacji aplikacji tworzonych jest kilka kopii obiektu HttpApplication, z których każda w danej chwili obsługuje tylko jedno żądanie. Obiekt taki odpowiada za obsłużenie całego żądania, a po jego zakończeniu może rozpocząć obsługę kolejnego. Dana obiekt odpowiada za całą obsługę konkretnego żądania w czasie jego istnienia.

Wyobraź sobie, że jesteś właścicielem drogiej, ekskluzywnej restauracji, w której każdy z kelnerów obsługuje w danej chwili tylko jeden stolik. Gdy do restauracji przychodzi nowy klient, to tylko jeden kelner odpowiada za jego obsługę, czyli za posadzenie go przy stoliku, poinformowanie o serwowanych specjałach i dostarczeniu zamawianych dań (choć w dania zostaną podane przez kogoś innego, to jednak kelner odpowiada za to kiedy to nastąpi). Dokładnie w taki sam sposób kopia obiektu HttpApplication obsługuje „odebranie” żądania HTTP, przetworzenie wszelkich jego parametrów oraz wygenerowanie strony wynikowej (warto zwrócić uwagę, iż samo wygenerowanie strony wynikowej jest realizowane przez obiekt klasy HttpHandler, lecz obiekt HttpApplication określa kiedy to ma nastąpić).

Ponieważ klasa pliku global.asax jest klasą potomną klasy HttpApplication, a zatem dysponuje ona wieloma metodami i zdarzeniami swojej klasy bazowej. To właśnie te metody i zdarzenia zapewniają możliwość programowego dostępu do aplikacji ASP.NET. W pliku global.asax definiowane są procedury obsługujące zdarzenia generowane przez obiekt HttpApplication, od którego w całości zależy przetwarzanie aplikacji. Procedury te muszą być zgodne ze standardową konwencją określania nazw procedur obsługi zdarzeń — Application_NazwZdarzenia(arugmenty zdarzenia). Poniżej została podana przykładowa nazwa jednej z procedur obsługi zdarzeń, jakie można zdefiniować w pliku global.asax:

Application_Start(obj as object, e as eventargs)

Programowanie pliku global.asax

Pod wieloma względami działanie pliku global.asax przypomina działanie zwyczajnych stron ASP.NET. Można w nim używać dyrektyw (@ Imports, @ Application oraz @ Assembly), korzystać z możliwości dołączania plików po stronie serwera (SSI; patrz rozdział 19., pt.: „Oddzielanie kodu od treści”) oraz umieszczać bloki deklarowania kodu. Plik global.asax służy do implementacji wszelkich zdarzeń udostępnianych przez klasę HttpApplication i przedstawionych w tabeli 18.1 (wiele z nich będzie używanych także w rozdziale 20., pt.: „Testowanie stron ASP.NET”).

Tabela 18.1.              Zdarzenia klasy HttpApplication.

Przyjrzyjmy się jak to działa w praktyce. Przykłady plik global.asax został przedstawiony na listingu 18.1.

Listing 18.1.              Przykładowy plik global.asax.

1           <script language="VB" runat="server">

2...