Sdílet prostřednictvím

Nejčastější rozdíly mezi vývojovou a provozní konfigurací (C#)

  • Článek

Scott Mitchell

Stáhnout PDF

V předchozích kurzech jsme nasadili náš web zkopírováním všech příslušných souborů z vývojového prostředí do produkčního prostředí. Není však neobvyklé, že mezi prostředími existují rozdíly v konfiguraci, což vyžaduje, aby každé prostředí mělo jedinečný soubor Web.config. Tento kurz se zabývá typickými rozdíly v konfiguraci a strategiemi údržby samostatných informací o konfiguraci.

Úvod

Poslední dva kurzy vás provedly nasazením jednoduché webové aplikace. Kurz Nasazení webu pomocí klienta FTP ukázal, jak pomocí samostatného klienta FTP zkopírovat potřebné soubory z vývojového prostředí až do produkčního prostředí. Předchozí kurz Nasazení webu pomocí sady Visual Studio se podíval na nasazení pomocí nástroje Kopírovat web v sadě Visual Studio a možnosti Publikovat. V obou kurzech byl každý soubor v produkčním prostředí kopií souboru ve vývojovém prostředí. Není však neobvyklé, že konfigurační soubory v produkčním prostředí se liší od konfiguračních souborů ve vývojovém prostředí. Konfigurace webové aplikace je uložená v Web.config souboru a obvykle obsahuje informace o externích prostředcích, jako jsou databázové, webové a e-mailové servery. Také popisuje chování aplikace v určitých situacích, například postup, který se má provést, když dojde k neošetřené výjimce.

Při nasazování webové aplikace je důležité, aby správné informace o konfiguraci skončily v produkčním prostředí. Ve většině případů Web.config nelze soubor ve vývojovém prostředí zkopírovat do produkčního prostředí tak, jak je. Místo toho je potřeba do produkčního prostředí Web.config nahrát přizpůsobenou verzi nástroje . V tomto kurzu se stručně seznámíte s některými častějšími rozdíly v konfiguraci. obsahuje také souhrn některých technik pro udržování různých informací o konfiguraci mezi prostředími.

Typické rozdíly v konfiguraci mezi vývojovými a produkčními prostředími

Soubor Web.config obsahuje řadu informací o konfiguraci ASP.NET aplikace. Některé z těchto informací o konfiguraci jsou stejné bez ohledu na prostředí. Například nastavení ověřování a pravidla autorizace adresy URL uvedené v Web.config souborech <authentication> a <authorization> elementech jsou obvykle stejné bez ohledu na prostředí. Jiné informace o konfiguraci, například informace o externích prostředcích, se ale obvykle liší v závislosti na prostředí.

Připojovací řetězce databáze jsou ukázkovým příkladem informací o konfiguraci, které se liší v závislosti na prostředí. Když webová aplikace komunikuje s databázovým serverem, musí nejprve navázat připojení a toho se dosáhne prostřednictvím připojovací řetězec. I když je možné pevně zakódovat databázi připojovací řetězec přímo na webových stránkách nebo v kódu, který se k databázi připojuje, je nejlepší umístit její Web.config<connectionStrings> prvek tak, aby připojovací řetězec informace byly v jediném centralizovaném umístění. Často se během vývoje používá jiná databáze, než se používá v produkčním prostředí; v důsledku toho musí být připojovací řetězec informace pro každé prostředí jedinečné.

Poznámka

V dalších kurzech se seznámíme s nasazením aplikací řízených daty. V tomto okamžiku se podíváme na specifika způsobu ukládání připojovacích řetězců databáze v konfiguračním souboru.

Zamýšlené chování vývojového a produkčního prostředí se výrazně liší. Webová aplikace ve vývojovém prostředí je vytvářena, testována a laděna malou skupinou vývojářů. V produkčním prostředí stejnou aplikaci navštěvuje mnoho různých souběžných uživatelů. ASP.NET obsahuje řadu funkcí, které vývojářům pomáhají při testování a ladění aplikace, ale tyto funkce by v produkčním prostředí měly být z důvodů výkonu a zabezpečení zakázané. Podívejme se na několik takových nastavení konfigurace.

Nastavení konfigurace, která mají vliv na výkon

Při první návštěvě stránky ASP.NET (nebo poprvé po změně) musí být její deklarativní kód převeden na třídu a tato třída musí být zkompilována. Pokud webová aplikace používá automatickou kompilaci, je potřeba zkompilovat také třídu kódu na pozadí stránky. Prostřednictvím elementu Web.config souboru můžete nakonfigurovat řadu možností kompilace<compilation>.

Atribut debug je jedním z nejdůležitějších atributů v elementu <compilation> . debug Pokud je atribut nastaven na "true", kompilovaná sestavení obsahují symboly ladění, které jsou potřeba při ladění aplikace v sadě Visual Studio. Symboly ladění ale zvětšují velikost sestavení a při spuštění kódu vynucují další požadavky na paměť. Kromě toho platí, že pokud debug je atribut nastavený na hodnotu true, veškerý obsah vrácený nástrojem WebResource.axd není uložen v mezipaměti, což znamená, že pokaždé, když uživatel navštíví stránku, bude muset znovu stáhnout statický obsah vrácený nástrojem WebResource.axd.

Poznámka

WebResource.axd je integrovaná obslužná rutina HTTP zavedená v ASP.NET 2.0, kterou serverové ovládací prvky používají k načítání vložených prostředků, jako jsou soubory skriptů, obrázky, soubory CSS a další obsah. Další informace o tom, jak WebResource.axd funguje a jak ho můžete použít pro přístup k vloženým prostředkům z vlastních serverových ovládacích prvků, najdete v tématu Přístup k vloženým prostředkům prostřednictvím adresy URL pomocí WebResource.axd.

Atribut <compilation> elementu debug je ve vývojovém prostředí obvykle nastavený na hodnotu true. Ve skutečnosti musí být tento atribut nastaven na "true", aby bylo možné ladit webovou aplikaci; Pokud se pokusíte ladit ASP.NET aplikaci ze sady Visual Studio a debug atribut je nastaven na hodnotu "false", visual Studio zobrazí zprávu s vysvětlením, že aplikaci nelze ladit, dokud debug atribut není nastaven na hodnotu "true" a nenabídne tuto změnu za vás.

V produkčním debug prostředí byste nikdy neměli mít atribut nastavený na true, protože to má vliv na výkon. Podrobnější diskuzi k tomuto tématu najdete v blogovém příspěvku Scotta GuthriehoDon't Run Production ASP.NET Applications with Enabled (Nespouštět produkční ASP.NET aplikace s povolenými aplikacemidebug="true").

Vlastní chyby a trasování

Když v aplikaci ASP.NET dojde k neošetřené výjimce, přejde do modulu runtime, kde se stane jedna ze tří věcí:

  • Zobrazí se obecná chybová zpráva modulu runtime. Tato stránka informuje uživatele, že došlo k chybě za běhu, ale neposkytuje žádné podrobnosti o chybě.
  • Zobrazí se zpráva s podrobnostmi o výjimce, která obsahuje informace o výjimce, která byla právě vyvolána.
  • Zobrazí se vlastní chybová stránka, což je ASP.NET stránka, kterou vytvoříte a která zobrazuje libovolnou zprávu.

Co se stane při neošetřené výjimce, závisí na oddílu<customErrors>Web.config souboru.

Při vývoji a testování aplikace pomáhá zobrazit podrobnosti o výjimce v prohlížeči. Zobrazení podrobností o výjimce v aplikaci v produkčním prostředí ale představuje potenciální bezpečnostní riziko. Navíc je to nelichotivé a dělá váš web neprofesionální. V ideálním případě v případě neošetřené výjimky webová aplikace ve vývojovém prostředí zobrazí podrobnosti o výjimce, zatímco stejná aplikace v produkčním prostředí zobrazí vlastní chybovou stránku.

Poznámka

Výchozí <customErrors> nastavení oddílu zobrazuje zprávu s podrobnostmi o výjimce pouze v případě, že je stránka navštívena prostřednictvím místního hostitele, a jinak zobrazí obecnou chybovou stránku modulu runtime. Není to ideální, ale je to ujišťující vědět, že výchozí chování neodhaluje podrobnosti o výjimce návštěvníkům mimo místní prostředí. V dalším kurzu se podrobněji podíváme na tuto <customErrors> část a ukážeme si, jak zobrazit vlastní chybovou stránku, když dojde k chybě v produkčním prostředí.

Další funkcí ASP.NET, která je při vývoji užitečná, je trasování. Trasování, pokud je povolené, zaznamenává informace o jednotlivých příchozích požadavcích a poskytuje speciální webovou stránku Trace.axdpro zobrazení podrobností poslední žádosti. Trasování můžete zapnout a nakonfigurovat prostřednictvím elementu<trace> v Web.config.

Pokud povolíte trasování, ujistěte se, že je zakázané v produkčním prostředí. Vzhledem k tomu, že informace o trasování zahrnují soubory cookie, data relací a další potenciálně citlivé informace, je důležité zakázat trasování v produkčním prostředí. Dobrou zprávou je, že ve výchozím nastavení je trasování zakázané a Trace.axd soubor je přístupný pouze přes localhost. Pokud tato výchozí nastavení změníte při vývoji, ujistěte se, že jsou v produkčním prostředí vypnutá.

Techniky údržby samostatných informací o konfiguraci

Různá nastavení konfigurace ve vývojovém a produkčním prostředí komplikují proces nasazení. V předchozích dvou kurzech se v procesu nasazení zkopírovaly všechny potřebné soubory z vývoje do produkčního prostředí, ale tento přístup funguje jenom v případě, že jsou informace o konfiguraci v obou prostředích stejné. Existují různé techniky nasazení aplikace s různými informacemi o konfiguraci. Některé z těchto možností zařadme do katalogu pro hostované webové aplikace.

Ruční nasazení konfiguračního souboru produkčního prostředí

Nejjednodušším přístupem je udržovat dvě verze Web.config souboru: jednu pro vývojové prostředí a druhou pro produkční prostředí. Nasazení lokality do produkčního prostředí zahrnuje zkopírování všech souborů na produkční server ve vývojovém prostředí s výjimkouWeb.config souboru . Místo toho by se soubor specifický pro Web.config produkční prostředí zkopíroval do produkčního prostředí.

Tento přístup není příliš sofistikovaný, ale jeho implementace je snadná, protože informace o konfiguraci se mění zřídka. Nejvhodnější je pro aplikace s malým vývojovým týmem, které jsou hostované na jednom webovém serveru a jejichž konfigurační informace se často mění. Nejúdržnější je při ručním nasazení souborů aplikace pomocí samostatného klienta FTP. Pokud používáte nástroj Kopírovat web nebo Publikovat v sadě Visual Studio, budete muset před nasazením nejprve prohodit soubor specifický pro Web.config nasazení s souborem specifickým pro produkční prostředí a po dokončení nasazení ho zase prohodit.

Změna konfigurace během procesu sestavení nebo nasazení

V dosavadních diskuzích se předpokládá ad hoc proces sestavení a nasazení. Mnoho větších softwarových projektů má formalizované procesy, které využívají opensourcové nástroje, domácí nástroje nebo nástroje třetích stran. U takových projektů můžete pravděpodobně přizpůsobit proces sestavení nebo nasazení a odpovídajícím způsobem upravit informace o konfiguraci před jejich odesláním do produkčního prostředí. Pokud vytváříte webovou aplikaci pomocí nástroje MSBuild, NAnt nebo jiného nástroje pro sestavení, můžete pravděpodobně přidat krok sestavení, který upraví Web.config soubor tak, aby zahrnoval nastavení specifická pro produkční prostředí. Nebo se váš pracovní postup nasazení může programově připojit k serveru správy zdrojového kódu a načíst příslušný Web.config soubor.

Skutečný přístup k získání odpovídajících informací o konfiguraci do produkčního prostředí se výrazně liší v závislosti na vašich nástrojích a pracovním postupu. Proto se tímto tématem nebudeme dále zabývat. Pokud používáte oblíbený nástroj pro sestavování, jako je MSBuild nebo NAnt, můžete najít články a kurzy týkající se nasazení, které jsou pro tyto nástroje specifické, prostřednictvím vyhledávání na webu.

Správa rozdílů v konfiguraci prostřednictvím projektu nasazení webu Add-In

V roce 2006 microsoft vydal Add-In web Development Project for Visual Studio 2005. V roce 2008 byl vydán Add-In pro Visual Studio 2008. Tato Add-In umožňuje vývojářům ASP.NET vytvořit samostatný projekt nasazení webu společně s projektem webové aplikace, který při sestavení explicitně zkompiluje webovou aplikaci a zkopíruje soubory pro nasazení do místního výstupního adresáře. Projekt webové aplikace používá na pozadí nástroj MSBuild.

Ve výchozím nastavení se soubor vývojového Web.config prostředí zkopíruje do výstupního adresáře, ale můžete nastavit projekt nasazení webu a přizpůsobit

informace o konfiguraci, které se zkopírují do tohoto adresáře následujícími způsoby:

  • Prostřednictvím Web.config nahrazení oddílu souboru, ve kterém určíte oddíl, který se má nahradit, a soubor XML, který obsahuje nahrazovací text.
  • Zadáním cesty k externímu zdrojovému souboru konfigurace. Je-li vybrána tato možnost, zkopíruje projekt nasazení webu určitý Web.config soubor do výstupního adresáře (místo souboru použitého Web.config ve vývojovém prostředí).
  • Přidáním vlastních pravidel do souboru MSBuild používaného projektem nasazení webu.

Pokud chcete nasadit webovou aplikaci, sestavte projekt nasazení webu a zkopírujte soubory z výstupní složky projektu do produkčního prostředí.

Další informace o používání projektu nasazení webu najdete v tomto článku o projektech nasazení webu z dubna 2007 v časopisu MSDN Magazine nebo se podívejte na odkazy v části Další materiály na konci tohoto kurzu.

Poznámka

Projekt nasazení webu nelze použít s aplikací Visual Web Developer, protože projekt nasazení webu je implementován jako Add-In sady Visual Studio a edice Visual Studio Express (včetně sady Visual Web Developer) nepodporují doplňky.

Souhrn

Externí prostředky a chování webové aplikace při vývoji se obvykle liší od toho, kdy je stejná aplikace v produkčním prostředí. Například databázové připojovací řetězce, možnosti kompilace a chování při výskytu neošetřené výjimky se v jednotlivých prostředích běžně liší. Proces nasazení se musí těmto rozdílům přizpůsobit. Jak jsme probrali v tomto kurzu, nejjednodušším přístupem je ručně zkopírovat alternativní konfigurační soubor do produkčního prostředí. Elegantnější řešení jsou možná při použití projektu nasazení webu Add-In nebo s formalizovaným procesem sestavení nebo nasazení, který se může těmto přizpůsobením přizpůsobit.

Všechno nejlepší na programování!

Další čtení

Další informace o tématech probíraných v tomto kurzu najdete v následujících zdrojích informací:

PředchozíDalší