Konfigurace ASP.NET aplikací

9. prosince 2004

•

V tomto článku se zaměřím spíše na začátečníky. Budu se zabývat základy konfigurace ASP.NET aplikací – projdeme si základní možnosti nastavení pomocí konfiguračních souborů web.config a vysvětlíme si, co vlastně aplikaci ASP.NET tvoří.

Aplikace ASP.NET

Abychom mohli začít mluvit o konfiguraci ASP.NET aplikací, měli bychom si vysvětlit, co to vůbec aplikace ASP.NET je.

Aplikaci ASP.NET tvoří všechny soubory v daném virtuálním adresáři a jeho podadresářích. Jedná se zpravidla o soubory s příponou .aspx (stránky ASP.NET), .ascx (user controls), web.config (konfigurační soubory, jejich význam si dnes vysvětlíme), global.asax (soubor ve kterém jsou metody pro obsloužení událostí na úrovni aplikace), .dll (knihovny typů používané v dané aplikaci) a další soubory používané v ASP.NET.

Co do počtu souborů jsou omezeny pouze soubory global.asax, který smí být v celé aplikaci pouze jednou. Soubory web.config se v aplikaci mohou vyskytovat v počtu neomezeném, maximálně však jednou v každém adresáři. Knihoven může být neomezeně, musí však být umístěny v podadresáři bin dané aplikace.

Konfigurační soubory

Každá aplikace na platformě .net má svá konfigurační nastavení uložena v souborech s příponou .config. Slovo každá na začátku předchozí věty si brzy vysvětlíme. Abych nemluvil pořád příliš abstraktně, podíváme se na takový konfigurační soubor hned zkraje, abyste si udělali představu o čem to vlastně mluvím:

<?xml version=“1.0″ encoding=“UTF-8″ ?>
<configuration>
<appSettings>
  <add key=“ConnectionString“ value=“server=localhost;database=db;UID=user;pwd=heslo“ />
</appSettings>
<system.web>
  <compilation debug=“true“ />
  <customErrors mode=“Off“ />
  <authentication mode=“Forms“>
   <forms loginUrl=“Login.aspx“ protection=“All“ />
  </authentication>
</system.web>
</configuration>

Framework .NET nabízí vcelku efektivní model používající ke konfiguraci aplikací soubory ve formátu XML. Klasické windows aplikace mají data uložena v registru. V .NETu si aplikace svá konfigurační data nese s sebou ve svém konfigurační souboru. Jak jsem již řekl, soubory .config jsou založeny na formátu XML. To v důsledku znamená, že při tvorbě těchto souborů musíte dodržovat všechna pravidla pro tvorbu XML souborů. Především si dávejte pozor, aby byl soubor well-formed – pozor na uzavírací tagy a pamatujte, že XML rozlišuje velká a malá písmena. V konfiguračních souborech se používají dvě konvence pro psaní velkých a malých písmen: Camel (velbloudí styl zápisu – všechna slova začínají velkým písmenem vyjma prvního – tedy jako v ukázce výše, např. customErrors) nebo Pascal (tj., všechna slova začínají velkým písmenem – náš předchozí příklad bychom tedy pozměnili na CustomErrors). Nejsem si vědom pravidla o upřednostnění používání jednoho či druhého způsobu, je to spíše otázka vkusu a zvyklostí programátora. Rozhodně to nemá pražádný vliv na výkon vaší aplikace. Doporučuji však, abyste si vybrali jednu konvenci a používali ji všude, aby pak nevznikaly zbytečné chyby např. při uzavírání tagů (<customErrors></CustomErrors>) apod.

Konfigurační model v ASP.NET je založen na dědičnosti nastavení. Již jsem řekl, že soubor web.config může být v každém adresáři (nejvýše však jednou). Dědičnost nastavení v praxi znamená, že nastavení definovaná v souboru web.config jsou platná pro objekty aplikace v daném adresáři a jeho podadresářích. Podadresáře tedy dědí nastavení svých rodičovských adresářů, můžou však některá (nebo všechna) nastavení překrýt svým souborem web.config. Sekce, které v souboru web.config v podadresáři nepřekryjete se tedy převezmou ze souboru web.config rodičovského adresáře. Zní to dosti krkolomně, ale je to jednoduché. Pro lepší pochopení se podívejme na příklad:

V hlavním adresáři máme soubor web.config obsahující následující parametry nastavení:

<system.web>
<compilation debug=“false“ defaultLanguage=“c#“ />
<customErrors mode=“Off“ />
</system.web>

V podadresáři adr1 se nachází konfigurační soubor s kódem:

<system.web>
<compilation debug=“true“ />
</system.web>

V podadresáři adr2 je další soubor web.config:

<system.web>
<compilation defaultLanguage=“vb“ />
</system.web>

Dejme tomu, že aplikaci tvoří ještě další podadresáře, které nemají své soubory web.config. Chování souborů v jednotlivých adresářích je zhruba následující:

celá aplikace má nastaveny customErrors (co to přesně je není teď rozhodující) na Off
ve všech podadresářích vyjma podadresáře adr2 je defaultní programovací jazyk CSharp. V podadresáři adr2 a jeho podadresářích je defaultLanguage VB.NET
pouze v adresáři adr1 a jeho podadresářích je hodnota debug nastavena na true (co nastavuje parametr debug není také rozhodující, nicméně věřím, že jeho význam je jasný)

Někde před pár odstavci jsem vám slíbil vysvětlení spojení „každá aplikace“. Prozatím jsem vám zatajil existenci speciálního konfiguračního souboru – machine.config. Soubor machine.config obsahuje základní nastavení pro celý server. Jeho nastavení se vztahují ke všem aplikacím běžícím na daném serveru. Soubor machine.config se nachází ve složce c:\windows \microsoft.net\Framework\verzeframeworku\config. Každému doporučuji nahlédnout do tohoto souboru – je to dobrá dokumentace ke konfiguračním souborům. Uvidíte sami! Dáme-li si dohromady informace, které jsem vám zde odtajnil, tedy že existuje jakýsi soubor machine.config a že konfigurační model použitý v .net frameworku je založen na dědičnosti konfigurace, mělo by vám být jasné proč jsem napsal, že každá aplikace má svá konfigurační nastavení uložena v souboru .config. Z principu dědičnosti totiž vyplývá, že pokud nevytvoříte vlastní soubor web.config, vaše aplikace převezme nastavení ze souboru machine.config.

Struktura souboru web.config

Mají-li soubory web.config splňovat pravidla daná pro tvorbu xml souborů, první řádek obsahuje deklaraci xml:

<?xml version=“ 1.0″ encoding=“UTF-8″>

Tělo konfiguračního souboru je uzavřeno mezi tagy <configuration> a </configuration>. Veškeré konfigurační sekce a nastavení musí být právě uvnitř této značky. Konfiguračních sekcí je docela dost, navíc si můžete vytvářet své vlastní sekce. Mezi nejběžnější, alespoň z těch, které použijete zpočátku, patří <appSettings /> a <system.web />.

Sekce <appSettings />

Do této sekce se umísťují datové položky dané aplikace. Nejčastěji databázová připojení (jako v našem příkladu) nebo zkrátka nejrůznější řetězce, které potřebujete v celé aplikaci. Jako vysvětlení si dovolím malou ukázku:

Zde jsme definovali klíč identifikovatelný jako ConnectionString definující připojovací řetězec pro připojení k databázi. Teď však potřebujeme získat hodnotu tohoto klíče ze stránky ASP.NET. Např.:

SqlConnection conn = new SqlConnection(Configuration.AppSettings[„ConnectionString“]);

Výhoda tohoto přístupu je zřejmá. Přistupujete-li k databázi z různých stránek aplikace a změníte-li třeba heslo, stačí změnu zanést pouze do souboru web.config a nové heslo bude použito v celé aplikaci.

Sekce <system.web />

Sekce system.web slou ží k nastavení právě ASP.NET. Dnes uvedu pouze nejzajímavější a nejpoužívanější sekce patřící do <system.web />.

Sekce <authentication /> a <authorization /> slouží k nastavení autentizace (resp. autorizace) ASP.NET aplikací. Rozdíl mezi autentizací a autorizací spočívá v tom, že autentizace definuje, jakým způsobem má být uživatel přihlášen, zatímco autorizace je rozhodnutí aplikace, má-li být uživateli povolen přístup či nikoli. Ale to jsem trošku odbočil.

V sekci <compilation /> konfigurujete kompilaci ASP.NET stránek. V našich příkladech jsme použili např. parametr debug, který určuje, že aplikace má být zkompilována v režimu ladění. Další použitý parametr, defaultLanguage, definuje výchozí programovací jazyk.

Další vcelku používanou sekcí je <customErrors />, kde se definují vlastní chybová hlášení. Během vývoje aplikace je dobré nastavit atribut mode na Off, abyste viděli podrobné chybové hlášení , je-li aplikace hotova, měli byste atribut nastavit na On, abyste uživatele nezatěžovali dlouhými chybovými hlášeními nebo neprozrazovali části kódu záškodníkům.

Poslední možností atributu mode je RemoteOnly. RemoteOnly se chová stejně jako Off, je-li ke stránce přistupováno z jiného místa, než ze serveru, který stránku hostuje. Je-li ke stránce přistupováno přímo z hostujícího serveru, zobrazí se kompletní chybové hlášení.

K tagu <customErrors /> může přidat ještě atribut defaultRedirect, který specifikuje cestu k vaší vlastní stránce s chybovým hlášením.

Sekce <customErrors /> může vypadat například takto: <customErrors mode="On" defaultRedirect="errorpage.aspx" /> v případě finální verze webu, resp. <customErrors mod e="Off" /> během vývoje webu.

V sekci <customErrors /> můžete také měnit chybová hlášení http (např. 403 – access denied nebo 404 – page not found). Uvedu jen příklad, protože si myslím, že z něj bude vše patrné:

V tomto textu jsem se vám pokusil objasnit základní principy fungování konfiguračních souborů na platformě .net. Závěrečný stručný seznam sekcí berte pouze jako ukázku nejzákladnějších bloků se kterými se během své praxe určitě setkáte a jejichž znalost považuji za důležitou.