Differenze di configurazione più comuni tra sviluppo e produzione (C#)

di Scott Mitchell

Scarica il PDF

Nelle esercitazioni precedenti è stato distribuito il sito Web copiando tutti i file pertinenti dall'ambiente di sviluppo all'ambiente di produzione. Tuttavia, non è raro che esistano differenze di configurazione tra gli ambienti, che richiedono che ogni ambiente abbia un file Web.config univoco. Questa esercitazione esamina le differenze di configurazione tipiche e esamina le strategie per la gestione di informazioni di configurazione separate.

Introduzione

Nelle ultime due esercitazioni è stata illustrata la distribuzione di una semplice applicazione Web. L'esercitazione Distribuzione del sito tramite un client FTP ha illustrato come usare un client FTP autonomo per copiare i file necessari dall'ambiente di sviluppo fino all'ambiente di produzione. L'esercitazione precedente, Distribuzione del sito tramite Visual Studio, ha esaminato la distribuzione usando lo strumento Copia sito Web di Visual Studio e l'opzione Pubblica. In entrambe le esercitazioni ogni file nell'ambiente di produzione era una copia di un file nell'ambiente di sviluppo. Tuttavia, non è insolito che i file di configurazione nell'ambiente di produzione differiscano da quelli nell'ambiente di sviluppo. La configurazione di un'applicazione Web viene archiviata nel Web.config file e in genere include informazioni sulle risorse esterne, ad esempio database, Web e server di posta elettronica. Specifica anche il comportamento dell'applicazione in determinate situazioni, ad esempio il corso di azione da eseguire quando si verifica un'eccezione non gestita.

Quando si distribuisce un'applicazione Web, è importante che le informazioni di configurazione corrette vengano restituite nell'ambiente di produzione. Nella maggior parte dei casi il Web.config file nell'ambiente di sviluppo non può essere copiato nell'ambiente di produzione così come è. È invece necessario caricare una versione personalizzata di nell'ambiente di Web.config produzione. Questa esercitazione esamina brevemente alcune delle differenze di configurazione più comuni; vengono inoltre riepilogate alcune tecniche per la gestione di informazioni di configurazione diverse tra gli ambienti.

Differenze di configurazione tipiche tra gli ambienti di sviluppo e produzione

Il Web.config file include un assortimento di informazioni di configurazione per un'applicazione ASP.NET. Alcune di queste informazioni di configurazione sono le stesse indipendentemente dall'ambiente. Ad esempio, le impostazioni di autenticazione e le regole di autorizzazione URL specificate negli elementi e <authorization> del <authentication>Web.config file sono in genere uguali indipendentemente dall'ambiente. Altre informazioni di configurazione, ad esempio informazioni sulle risorse esterne, in genere variano a seconda dell'ambiente.

Le stringhe di connessioni al database sono un primo esempio di informazioni di configurazione che differiscono in base all'ambiente. Quando un'applicazione Web comunica con un server di database, deve prima stabilire una connessione e che viene ottenuta tramite un stringa di connessione. Anche se è possibile impostare come hardcoded il database stringa di connessione direttamente nelle pagine Web o nel codice che si connette al database, è preferibile posizionarlo Web.config<connectionStrings> in modo che le informazioni stringa di connessione si trovano in un'unica posizione centralizzata. Spesso viene usato un database diverso durante lo sviluppo rispetto a quello usato nell'ambiente di produzione; di conseguenza, le informazioni stringa di connessione devono essere univoce per ogni ambiente.

Il comportamento previsto degli ambienti di sviluppo e produzione differisce sostanzialmente. Un'applicazione Web nell'ambiente di sviluppo viene creata, testata e sottoposta a debug da un piccolo gruppo di sviluppatori. Nell'ambiente di produzione in cui viene visitata la stessa applicazione da molti utenti simultanei diversi. ASP.NET include una serie di funzionalità che consentono agli sviluppatori di testare e eseguire il debug di un'applicazione, ma queste funzionalità devono essere disabilitate per motivi di prestazioni e sicurezza quando si trova nell'ambiente di produzione. Verranno ora esaminate alcune impostazioni di configurazione di questo tipo.

Impostazioni di configurazione che influisce sulle prestazioni

Quando viene visitata una pagina ASP.NET per la prima volta (o la prima volta dopo la modifica), il markup dichiarativo deve essere convertito in una classe e questa classe deve essere compilata. Se l'applicazione Web usa la compilazione automatica, è necessario compilare anche la classe code-behind della pagina. È possibile configurare un assortimento di opzioni di compilazione tramite l'elemento Web.config del <compilation>file.

L'attributo di debug è uno degli attributi più importanti nell'elemento <compilation> . Se l'attributo debug è impostato su "true", gli assembly compilati includono simboli di debug, necessari per il debug di un'applicazione in Visual Studio. Tuttavia, i simboli di debug aumentano le dimensioni dell'assembly e impongono requisiti di memoria aggiuntivi durante l'esecuzione del codice. Inoltre, quando l'attributo debug è impostato su "true" qualsiasi contenuto restituito da WebResource.axd non viene memorizzato nella cache, ovvero ogni volta che un utente visita una pagina dovrà scaricare nuovamente il contenuto statico restituito da WebResource.axd.

L'attributo <compilation> dell'elemento debug è in genere impostato su "true" nell'ambiente di sviluppo. In realtà, questo attributo deve essere impostato su "true" per eseguire il debug di un'applicazione Web; Se si tenta di eseguire il debug di un'applicazione ASP.NET da Visual Studio e l'attributo debug è impostato su "false", Visual Studio visualizzerà un messaggio che spiega che l'applicazione non può essere sottoposto a debug finché l'attributo debug non è impostato su "true" e offrirà di apportare questa modifica automaticamente.

L'attributo debugnon deve mai essere impostato su "true" in un ambiente di produzione a causa dell'impatto sulle prestazioni. Per una discussione più approfondita su questo argomento, vedere il post di blog di Scott Guthrie, Don't Run Production ASP.NET Applications With Enabled (Non eseguire la produzione ASP.NET applicazioni con debug="true" abilitato).

Errori personalizzati e traccia

Quando si verifica un'eccezione non gestita in un'applicazione ASP.NET si sposta fino al runtime, a questo punto si verifica una delle tre cose seguenti:

• Viene visualizzato un messaggio di errore di runtime generico. Questa pagina informa l'utente che si è verificato un errore di runtime, ma non fornisce dettagli sull'errore.
• Viene visualizzato un messaggio di dettagli dell'eccezione, che include informazioni sull'eccezione appena generata.
• Viene visualizzata una pagina di errore personalizzata, ovvero una pagina di ASP.NET creata che visualizza qualsiasi messaggio desiderato.

Ciò che accade in caso di eccezione non gestita dipende Web.config dalla sezione del <customErrors>file.

Quando si sviluppa e si testa un'applicazione, è possibile visualizzare i dettagli di qualsiasi eccezione nel browser. Tuttavia, la visualizzazione dei dettagli delle eccezioni in un'applicazione nell'ambiente di produzione è un potenziale rischio per la sicurezza. Inoltre, è poco gonfiante e rende il tuo sito web un aspetto poco professionale. Idealmente, in caso di eccezione non gestita, un'applicazione Web nell'ambiente di sviluppo mostrerà i dettagli dell'eccezione mentre la stessa applicazione nell'ambiente di produzione mostrerà una pagina di errore personalizzata.

Un'altra funzionalità ASP.NET utile durante lo sviluppo è la traccia. La traccia, se abilitata, registra informazioni su ogni richiesta in ingresso e fornisce una pagina Web speciale, Trace.axd, per visualizzare i dettagli delle richieste recenti. È possibile attivare e configurare la traccia tramite l'elemento<trace> in Web.config.

Se si abilita la traccia, assicurarsi che sia disabilitata nell'ambiente di produzione. Poiché le informazioni di traccia includono cookie, dati di sessione e altre informazioni potenzialmente sensibili, è importante disabilitare la traccia nell'ambiente di produzione. La buona notizia è che, per impostazione predefinita, la traccia è disabilitata e il Trace.axd file è accessibile solo tramite localhost. Se si modificano queste impostazioni predefinite nello sviluppo, assicurarsi che vengano disattivate nell'ambiente di produzione.

Tecniche per la gestione di informazioni di configurazione separate

La presenza di impostazioni di configurazione diverse negli ambienti di sviluppo e produzione complica il processo di distribuzione. Nelle due esercitazioni precedenti il processo di distribuzione implicava la copia di tutti i file necessari dallo sviluppo alla produzione, ma tale approccio funziona solo se le informazioni di configurazione sono uguali in entrambi gli ambienti. Esistono diverse tecniche per la distribuzione di un'applicazione con informazioni di configurazione diverse. Verranno ora elencate alcune di queste opzioni per le applicazioni Web ospitate.

Distribuzione manuale del file di configurazione dell'ambiente di produzione

L'approccio più semplice consiste nel gestire due versioni del Web.config file: una per l'ambiente di sviluppo e una per l'ambiente di produzione. La distribuzione di un sito nell'ambiente di produzione comporta la copia di tutti i file nel server di produzione nell'ambiente di sviluppo , ad eccezione del Web.config file . Al contrario, il file specifico Web.config dell'ambiente di produzione verrà copiato nell'ambiente di produzione.

Questo approccio non è molto sofisticato, ma è facile da implementare perché le informazioni di configurazione cambiano raramente. È ideale per le applicazioni con un piccolo team di sviluppo ospitato in un singolo server Web e le cui informazioni di configurazione vengono modificate raramente. È più tenable quando si distribuiscono manualmente i file dell'applicazione usando un client FTP autonomo. Quando si usa lo strumento Copia sito Web di Visual Studio o l'opzione Pubblica, è necessario prima scambiare il file specifico Web.config della distribuzione con quello specifico per la produzione prima della distribuzione e quindi scambiarli di nuovo dopo il completamento della distribuzione.

Modificare la configurazione durante il processo di compilazione o distribuzione

Le discussioni finora hanno assunto un processo di compilazione e distribuzione ad hoc. Molti progetti software più grandi hanno processi più formalizzati che usano strumenti open source, cresciuti a casa o di terze parti. Per tali progetti è probabilmente possibile personalizzare il processo di compilazione o distribuzione per modificare in modo appropriato le informazioni di configurazione prima che venga eseguito il push nell'ambiente di produzione. Se si compila l'applicazione Web usando MSBuild, NAnt o un altro strumento di compilazione, è probabile che sia possibile aggiungere un passaggio di compilazione per modificare il Web.config file in modo da includere le impostazioni specifiche di produzione. In alternativa, il flusso di lavoro di distribuzione può connettersi al server di controllo del codice sorgente e recuperare il file appropriato Web.config .

L'approccio effettivo per ottenere le informazioni di configurazione appropriate per la produzione varia notevolmente in base agli strumenti e al flusso di lavoro. Di conseguenza, non verranno approfonditi ulteriormente questo argomento. Se si usa uno strumento di compilazione comune come MSBuild o NAnt, è possibile trovare articoli di distribuzione ed esercitazioni specifici per questi strumenti tramite una ricerca Web.

Gestione delle differenze di configurazione tramite il progetto di distribuzione Web Add-In

Nel 2006 Microsoft ha rilasciato il progetto di sviluppo Web Add-In per Visual Studio 2005. Nel 2008 è stata rilasciata una Add-In per Visual Studio 2008. Questa Add-In consente agli sviluppatori di ASP.NET di creare un progetto di distribuzione Web separato insieme al progetto dell'applicazione Web che, quando compilato, compila in modo esplicito l'applicazione Web e copia i file da distribuire in una directory di output locale. Il progetto applicazione Web usa MSBuild dietro le quinte.

Per impostazione predefinita, il file dell'ambiente di sviluppo viene copiato nella directory di Web.config output, ma è possibile configurare il progetto di distribuzione Web per personalizzare

informazioni di configurazione copiate in questa directory nei modi seguenti:

• Tramite Web.config sostituzione della sezione file, in cui si specifica la sezione da sostituire e un file XML contenente il testo sostitutivo.
• Fornendo un percorso a un file di origine di configurazione esterno. Con questa opzione selezionata, il progetto di distribuzione Web copia un Web.config determinato file nella directory di output ( anziché il Web.config file usato nell'ambiente di sviluppo).
• Aggiungendo regole personalizzate al file MSBuild usato dal progetto di distribuzione Web.

Per distribuire l'applicazione Web creare il progetto di distribuzione Web e quindi copiare i file dalla cartella di output del progetto all'ambiente di produzione.

Per altre informazioni sull'uso del progetto di distribuzione Web, vedere l'articolo Progetti di distribuzione Web dal numero di aprile 2007 di MSDN Magazine oppure consultare i collegamenti nella sezione Altre letture alla fine di questa esercitazione.

Riepilogo

Le risorse esterne e il comportamento di un'applicazione Web in fase di sviluppo sono in genere diversi da quando la stessa applicazione è in produzione. Ad esempio, le stringhe di connessione del database, le opzioni di compilazione e il comportamento quando si verifica un'eccezione non gestita differiscono comunemente tra ambienti. Il processo di distribuzione deve soddisfare queste differenze. Come illustrato in questa esercitazione, l'approccio più semplice consiste nel copiare manualmente un file di configurazione alternativo nell'ambiente di produzione. Le soluzioni più eleganti sono possibili quando si usa il progetto di distribuzione Web Add-In o con un processo di compilazione o distribuzione più formale che può supportare tali personalizzazioni.

Programmazione felice!

Altre informazioni

Per altre informazioni sugli argomenti illustrati in questa esercitazione, vedere le risorse seguenti:

• Stringhe di connessione illustrate
• Stringhe di connessione del database @ ConnectionStrings.com
• Non eseguire applicazioni di produzione ASP.NET con debug="true" abilitato
• Risposta con tolleranza alle eccezioni non gestite - Visualizzazione di pagine di errore User-Friendly
• Impostazioni di configurazione delle chiavi durante la distribuzione di un database.
• Progetti | di distribuzione Web VS 2008Supporto del progetto di distribuzione Web VS 2008 rilasciato
• Progetti di distribuzione Web