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

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 vi siano differenze di configurazione tra 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

Le ultime due esercitazioni illustrano la distribuzione di un'applicazione Web semplice. 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 è stata una copia di un file nell'ambiente di sviluppo. Tuttavia, non è raro 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 dell'azione da eseguire quando si verifica un'eccezione non gestita.

Quando si distribuisce un'applicazione Web, è importante che le informazioni di configurazione corrette finissono 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, deve essere caricata in produzione una versione personalizzata di Web.config . Questa esercitazione esamina brevemente alcune delle differenze di configurazione più comuni; riepiloga anche alcune tecniche per mantenere 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 uguali indipendentemente dall'ambiente. Ad esempio, le impostazioni di autenticazione e le regole di autorizzazione URL <authentication> specificate negli elementi e <authorization> del Web.config file sono in genere uguali indipendentemente dall'ambiente. Altre informazioni di configurazione, ad esempio informazioni sulle risorse esterne, in genere differiscono a seconda dell'ambiente.

Le stringhe di connessione del database sono un esempio principale 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. Sebbene sia possibile eseguire il hardcodeing del database stringa di connessione direttamente nelle pagine Web o nel codice che si connette al database, è consigliabile posizionare Web.config<connectionStrings> l'elemento in modo che le informazioni stringa di connessione si trovano in una singola posizione centralizzata. Spesso un database diverso viene usato 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 notevolmente. Un'applicazione Web nell'ambiente di sviluppo viene creata, testata e sottoposta a debug da un piccolo gruppo di sviluppatori. Nell'ambiente di produzione che la stessa applicazione viene visitata da molti utenti simultanei diversi. ASP.NET include numerose 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 esaminate alcune impostazioni di configurazione.

Impostazioni di configurazione che influisce sulle prestazioni

Quando viene visitata una pagina ASP.NET per la prima volta (o la prima volta che è stata modificata), il markup dichiarativo deve essere convertito in una classe e questa classe deve essere compilata. Se l'applicazione Web usa la compilazione automatica, anche la classe code-behind della pagina deve essere compilata. È 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 dell'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. Ma 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 che dovrà scaricare nuovamente il contenuto statico restituito da WebResource.axd.

L'attributo <compilation> dell'elemento è in genere impostato su "true" nell'ambiente di debug sviluppo. Questo attributo deve infatti 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 eseguita il debug fino a quando l'attributo debug non è impostato su "true" e offrirà questa modifica per l'utente.

L'attributo non deve mai essere impostato su "true" in un ambiente di produzione a causa dell'impatto debug 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 debug="true" Enabled.

Errori personalizzati e traccia

Quando si verifica un'eccezione non gestita in un'applicazione ASP.NET, il runtime viene generato fino al runtime a cui 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 eccezione, che include informazioni sull'eccezione appena generata.
• Viene visualizzata una pagina di errore personalizzata, ovvero una pagina ASP.NET creata che visualizza qualsiasi messaggio desiderato.

Ciò che accade a fronte di un'eccezione non gestita dipende Web.config dalla sezione del <customErrors>file.

Durante lo sviluppo e il test di un'applicazione consente di visualizzare i dettagli di qualsiasi eccezione nel browser. Tuttavia, mostrando i dettagli delle eccezioni in un'applicazione in produzione è un potenziale rischio di sicurezza. Inoltre, non è più gonfiabile e rende il tuo sito web non 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 è traccia. Traccia, se abilitata, registra informazioni su ogni richiesta in ingresso e fornisce una pagina Web speciale, , Trace.axdper 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 sulla 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

L'uso di impostazioni di configurazione diverse negli ambienti di sviluppo e produzione complica il processo di distribuzione. Nelle due esercitazioni precedenti il processo di distribuzione implica la copia di tutti i file necessari dallo sviluppo all'ambiente di 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 variabili. Ecco 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 Web.config mantenere due versioni del file: una per l'ambiente di sviluppo e una per l'ambiente di produzione. La distribuzione di un sito in produzione comporta la copia di tutti i file nel server di produzione nell'ambiente di sviluppo , ad eccezione del Web.config file. Invece, il file specifico Web.config dell'ambiente di produzione verrà copiato in produzione.

Questo approccio non è molto sofisticato, ma è facile da implementare perché le informazioni di configurazione cambiano raramente. Funziona meglio per le applicazioni con un piccolo team di sviluppo ospitato in un singolo server Web e le cui informazioni di configurazione vengono raramente modificate. È più tenibile 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 della distribuzione con quello specifico Web.config di produzione prima della distribuzione e quindi scambiarli nuovamente 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 alcuni altri strumenti di compilazione, è possibile aggiungere probabilmente un passaggio di compilazione per modificare il Web.config file in modo da includere le impostazioni specifiche di produzione. Oppure il flusso di lavoro di distribuzione può connettersi a livello di codice 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 ampiamente in base agli strumenti e al flusso di lavoro. Di conseguenza, non si apprenderà più in questo argomento. Se si usa uno strumento di compilazione popolare, ad esempio MSBuild o NAnt, è possibile trovare articoli e esercitazioni di distribuzione specifici di 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. Una Add-In per Visual Studio 2008 è stata rilasciata nel 2008. Questo 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 in background.

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 che contiene 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 determinato Web.config 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 compilare 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 questo articolo relativo ai progetti di distribuzione Web dal numero di aprile 2007 di MSDN Magazine oppure consultare i collegamenti nella sezione Altre informazioni 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 gli 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ù formalizzato in grado di supportare tali personalizzazioni.

Buon programmatori!

Altre informazioni

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

• Spiegazione delle stringhe di connessione
• Stringhe di connessione del database @ ConnectionStrings.com
• Non eseguire applicazioni ASP.NET di produzione con debug="true" abilitato
• Risposta normale alle eccezioni non gestite: visualizzazione di pagine di errore User-Friendly
• Impostazioni di configurazione chiave durante la distribuzione di un database
• Progetti di distribuzione Web vs | 2008Rilascio del supporto del progetto di distribuzione Web vs 2008
• Progetti di distribuzione Web