r18 t

[ Pobierz całość w formacie PDF ]
.NET w globalnej pamięci podręcznej.Jako parametr należy podać nazwę pliku zawierającego manifest.Przykład użycia:/i myDll.dll/uUsuwa komponent.NET z globalnej pamięci podręcznej.Jako parametr należy podać nazwę usuwanego komponentu:Przykłady:/u myDll/u myDll,Ver=1.1.0,Loc=en,PK=874e23ab87e23ab/lWyświetla listę komponentów zainstalowanych w globalnej pamięci podręcznej./?Wyświetla informacje dotyczące sposobu wywołania programuNależy zachować dużą ostrożność podczas usuwania komponentów.NET z globalnej pamięci podręcznej gdyż wydanie polecenia gacutil /u myDll spowoduje usunięcie wszystkich wersji biblioteki myDll.Dlatego też zawsze należy podawać wszystkie konieczne informacje.Z lokalnych pamięci podręcznych komponentów.NET mogą korzystać wyłącznie aplikacje, do których dana pamięć podręczna należy.Rolę domyślnej lokalnej pamięci podręcznej pełni folder \bin znajdujący się w folderze głównym aplikacji ASP.NET.Folder ten jest konfigurowany w taki sposób, że bezpośrednie żądania kierowane przez klienty nie mogą korzystać z jego zasobów.To bardzo przydatne rozwiązanie, dzięki któremu nikt nie będzie w stanie ukraść zgromadzonego w nim kodu.Przyjrzymy się prostej, przykładowej strukturze folderów witryny WWW przedstawionej w tabeli 18.3.Tabela 18.3.Przykładowa struktura folderów serwera WWW.Adres URL aplikacjiFizyczna ścieżka dostępu do folderahttp://www.witryna.comc:\inetpub\wwwroothttp://www.witryna.com:85c:\inetpub\wwwroot\port85http://www.witryna.com/gryd:\www\gameshttp://www.witryna.com/gry/uzytkownicyd:\www\uzytkownicyKażdy z fizycznych folderów podanych w powyższej tabeli jest jednocześnie katalogiem wirtualnym zdefiniowanym w serwerze IIS, a zatem, stanowi niezależną aplikację ASP.NET.Każda z tych aplikacji może dysponować swoją własną, lokalną pamięcią podręczną zlokalizowaną w folderze \bin, na przykład, dla aplikacji www.witryna.com będzie to folder c:\inetpub\wwwroot\bin.Każda z tych lokalnych pamięci podręcznych może być wykorzystywana wyłącznie przez aplikację do której należy.Dzięki temu, na jednej witrynie można korzystać z kilku różnych wersji tego samego komponentu.NET!Lustrzane kopie komponentów.NETZazwyczaj gdy wirtualna maszyna CLR ładuje do pamięci bibliotekę DLL komponentu blokuje do dostęp do pliku, dzięki czemu żadna inna aplikacja nie ma do niego dostępu i nie może go uszkodzić.Plik jest odblokowywany gdy zostanie zniszczona korzystająca z niego domena aplikacji.Rozwiązanie to zapewnia doskonałą stabilność lecz jednocześnie sprawia, że koszty wymiany plików są niezwykle wysokie.Na przykład, w przypadku wcześniejszych wersji technologii ASP, biblioteki DLL byłyby zablokowane aż do czasu ponownego uruchomienia serwera — to duży problem zarówno dla administratorów jak i użytkowników aplikacji.W ASP.NET problem został rozwiązany w inny sposób.Otóż komponenty.NET nie są ładowane do pamięci — zamiast tego, bezpośrednio przed użyciem komponentów tworzone są ich lustrzane kopie i to właśnie one są blokowane i ładowane do pamięci.Ponieważ faktyczne pliki komponentów nie są blokowane, programiści mogą je wymieniać bez konieczności ponownego uruchamiania serwera.ASP.NET monitoruje i wykrywa wszelkie zmiany w plikach komponentów.NET.W przypadku wykrycia zmiany jest tworzona nowa lustrzana kopia komponentu, która następnie zostanie załadowana do pamięci i stopniowo przejmuje obsługę żądań realizowaną do tej pory przez poprzednią kopię.Kiedy wszystkie żądania będą już obsługiwane przez nową wersję kopii komponentu, poprzednia kopia zostaje zniszczona.Cały ten proces jest zazwyczaj niewidoczny dla użytkownika końcowego.A ile problemów może on zaoszczędzić programistom i administratorom!To nie jest ASP!Informacje podane w tym rozdziale uwidaczniają kilka znaczących zmian jakie wprowadzono w ASP.NET w porównaniu z tradycyjną wersją technologii ASP.Proces konfiguracji aplikacji oraz ich wdrażania został znacznie zmieniony i uproszczony.Przyzwyczajenie się do niego może jednak zabrać nieco czasu.Jednym z elementów, który nie uległ zmianie (przynajmniej pod względem implementacji) jest użycie pliku w celu kontroli zdarzeń zachodzących w aplikacji.We wcześniejszych wersjach technologii ASP był to plik global.asa, w ASP.NET nosi on nazwę global.asax.Oba pliki są ze sobą w pełni zgodne.Przenosząc aplikacje ASP do ASP.NET można po prostu zapisać zawartość pliku global.asa w pliku global.asax i mieć pewność że aplikacja cały czas będzie działać poprawnie.Oczywiście są pewne niezauważalne różnice.Jedną z nich tej fakt, iż plik global.asax jest kompilowany do postaci klasy.NET.W tradycyjnej technologii ASP plik global.asa był interpretowany, podobnie zresztą jak wszystkie strony ASP.Bardzo duże zmiany zostały wprowadzone w systemie konfiguracji aplikacji ASP.NET.W tradycyjnej wersji technologii ASP wszelkie ustawienia konfiguracyjne trzeba było wprowadzać za pośrednictwem narzędzi administracyjnych serwera IIS lub innych aplikacji systemowych.Zazwyczaj wiązało się to z koniecznością przeprowadzania konfiguracji bezpośrednio komputerze pełniącym funkcję serwera WWW.Co więcej, określanie różnych ustawień dla różnych aplikacji lub wybranych elementów wchodzących w skład aplikacji było dosyć trudne.W ASP.NET wszystkie ustawienia konfiguracyjne dostępne w tradycyjnej wersji technologii ASP są teraz podawane w plikach XML.Oznacza to, że modyfikacja ustawień konfiguracyjnych stała się bardzo prosta — wystarczy użyć dowolnego edytora tekstowego i przesłać je na serwer.Poza tym, hierarchiczny system konfiguracyjny wykorzystywany w ASP.NET zapewnia znacznie dokładniejszą i wybiórczą kontrolę nad aplikacją, niż było to możliwe w tradycyjnej technologii ASP.Podawane ustawienia konfiguracyjne mogą dotyczyć wyłącznie określonego pliku lub folderu, precyzyjnie określać sposób działania procesu ASP.NET, a nawet wskazywać miejsce gdzie mają być przechowywane informacje o sesjach.Pliki web.config są w pełni rozszerzalne i pozwalają na stosowanie własnych ustawień konfiguracyjnych.I w końcu ostatnia sprawa — nowy sposób wdrażania aplikacji może być prawdziwym rajem dla programistów ASP.Nie trzeba przeprowadzać żadnej instalacji, żadnego rejestrowania komponentów, a ustawienia konfiguracyjne można z łatwością przekazywać z serwera na serwer.W zasadzie uruchomienie aplikacji na innym serwerze sprowadza się do skopiowania odpowiednich plików.Wdrażanie aplikacji internetowych nigdy nie było prostsze.2 Część I ♦ Podstawy obsługi systemu WhizBang (Nagłówek strony)2 Dokument2W tekście jest błąd - ma być Application_Start.Sposób zapisu na podstawie dokumentacji [ Pobierz całość w formacie PDF ]

Linki