Distribuzione di un'applicazione Web ASP.NET con SQL Server Compact con Visual Studio o Visual Web Developer: Trasformazioni di file Web.Config - 3 di 12
di Tom Dykstra
Scaricare il progetto iniziale
Questa serie di esercitazioni illustra come distribuire (pubblicare) un progetto di applicazione Web ASP.NET che include un database sql Server Compact usando Visual Studio 2012 RC o Visual Studio Express 2012 RC per Web. È anche possibile usare Visual Studio 2010 se si installa l'aggiornamento di pubblicazione Web. Per un'introduzione alla serie, vedere la prima esercitazione della serie.
Per un'esercitazione che illustra le funzionalità di distribuzione introdotte dopo la versione RC di Visual Studio 2012, illustra come distribuire edizioni di SQL Server diverse da SQL Server Compact e illustra come eseguire la distribuzione in app Azure Service App Web, vedere ASP.NET Distribuzione Web con Visual Studio.
Panoramica
Questa esercitazione illustra come automatizzare il processo di modifica del file Web.config quando viene distribuito in ambienti di destinazione diversi. La maggior parte delle applicazioni ha impostazioni nel file Web.config che devono essere diverse quando l'applicazione viene distribuita. L'automazione del processo di esecuzione di queste modifiche impedisce di doverle eseguire manualmente ogni volta che si distribuisce, che sarebbe noioso e soggetto a errori.
Promemoria: se viene visualizzato un messaggio di errore o qualcosa non funziona durante l'esercitazione, assicurarsi di controllare la pagina di risoluzione dei problemi.
Trasformazioni Web.config e parametri di distribuzione Web
Esistono due modi per automatizzare il processo di modifica delle impostazioni del file Web.config : trasformazioni Web.config e parametri distribuzione Web. Un file di trasformazione Web.config contiene markup XML che specifica come modificare il file Web.config quando viene distribuito. È possibile specificare modifiche diverse per configurazioni di compilazione specifiche e per profili di pubblicazione specifici. Le configurazioni di compilazione predefinite sono Debug e Release ed è possibile creare configurazioni di compilazione personalizzate. Un profilo di pubblicazione corrisponde in genere a un ambiente di destinazione. Altre informazioni sui profili di pubblicazione sono disponibili in Esercitazione sulla distribuzione in IIS come ambiente di test.
I parametri distribuzione Web possono essere usati per specificare molti tipi diversi di impostazioni che devono essere configurati durante la distribuzione, incluse le impostazioni disponibili nei file Web.config . Se usato per specificare le modifiche al file Web.config , i parametri di distribuzione Web sono più complessi da configurare, ma sono utili quando non si conosce il valore da impostare fino alla distribuzione. Ad esempio, in un ambiente aziendale, è possibile creare un pacchetto di distribuzione e assegnarlo a una persona del reparto IT da installare nell'ambiente di produzione e tale persona deve essere in grado di immettere stringa di connessione o password che non si conoscono.
Per lo scenario illustrato in questa esercitazione, è necessario conoscere tutti gli elementi che devono essere eseguiti nel file Web.config , pertanto non è necessario usare i parametri distribuzione Web. Verranno configurate alcune trasformazioni diverse a seconda della configurazione di compilazione usata e alcune che differiscono a seconda del profilo di pubblicazione usato.
Creazione di file di trasformazione per i profili di pubblicazione
In Esplora soluzioni espandere Web.config per visualizzare i file di trasformazione Web.Debug.config e Web.Release.config creati per impostazione predefinita per le due configurazioni di compilazione predefinite.
È possibile creare file di trasformazione per configurazioni di compilazione personalizzate facendo clic con il pulsante destro del mouse sul file Web.config e scegliendo Aggiungi trasformazioni di configurazione dal menu di scelta rapida, ma per questa esercitazione non è necessario eseguire questa operazione.
Sono necessari altri due file di trasformazione per la configurazione delle modifiche correlate alla destinazione della distribuzione anziché alla configurazione di compilazione. Un esempio tipico di questo tipo di impostazione è un endpoint WCF diverso per il test rispetto all'ambiente di produzione. Nelle esercitazioni successive verranno creati profili di pubblicazione denominati Test e Production, quindi sono necessari un file Web.Test.config e un file Web.Production.config .
I file di trasformazione associati ai profili di pubblicazione devono essere creati manualmente. In Esplora soluzioni fare clic con il pulsante destro del mouse sul progetto ContosoUniversity e scegliere Apri cartella in Esplora risorse.
In Esplora risorse selezionare il file Web.Release.config , copiare il file e quindi incollarne due copie. Rinominare queste copie Web.Production.config e Web.Test.config, quindi chiudere Esplora risorse.
In Esplora soluzioni fare clic su Aggiorna per visualizzare i nuovi file.
Selezionare i nuovi file, fare clic con il pulsante destro del mouse e quindi scegliere Includi nel progetto nel menu di scelta rapida.
Per impedire la distribuzione di questi file, selezionarli in Esplora soluzioni e quindi nella finestra Proprietà modificare la proprietà Azione di compilazione da Contenuto a Nessuno. I file di trasformazione basati sulle configurazioni di compilazione non vengono automaticamente distribuiti.
È ora possibile immettere le trasformazioni Web.config nei file di trasformazione Web.config .
Limitazione dell'accesso al log degli errori agli amministratori
Se si verifica un errore durante l'esecuzione dell'applicazione, l'applicazione visualizza una pagina di errore generica al posto della pagina di errore generata dal sistema e usa il pacchetto NuGet Elmah per la registrazione e la segnalazione degli errori. L'elemento customErrors nel file Web.config specifica la pagina di errore:
<customErrors mode="RemoteOnly" defaultRedirect="~/GenericErrorPage.aspx">
<error statusCode="404" redirect="~/GenericErrorPage.aspx" />
</customErrors>
Per visualizzare la pagina degli errori, modificare temporaneamente l'attributo mode dell'elemento customErrors da "RemoteOnly" a "Sì" ed eseguire l'applicazione da Visual Studio. Causare un errore richiedendo un URL non valido, ad esempio Studentsxxx.aspx. Anziché una pagina di errore "pagina non trovata" generata da IIS, viene visualizzata la pagina GenericErrorPage.aspx .
Per visualizzare il log degli errori, sostituire tutti gli elementi nell'URL dopo il numero di porta con elmah.axd (ad esempio nella schermata) http://localhost:51130/elmah.axde premere INVIO:
Non dimenticare di impostare di nuovo l'elemento sulla customErrors modalità "RemoteOnly" al termine.
Nel computer di sviluppo è utile consentire l'accesso gratuito alla pagina del log degli errori, ma nell'ambiente di produzione si tratta di un rischio per la sicurezza. Per il sito di produzione, è possibile aggiungere una regola di autorizzazione che limita l'accesso al log degli errori solo agli amministratori configurando una trasformazione nel file Web.Production.config .
Aprire Web.Production.config e aggiungere un nuovo location elemento immediatamente dopo il tag di apertura configuration , come illustrato di seguito. Assicurarsi di aggiungere solo l'elemento location e non il markup circostante visualizzato qui solo per fornire un contesto.
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<location path="elmah.axd" xdt:Transform="Insert">
<system.web>
<authorization>
<allow roles="Administrator" />
<deny users="*" />
</authorization>
</system.web>
</location>
</configuration>
Il Transform valore dell'attributo "Insert" determina l'aggiunta di questo location elemento come elemento di pari livello a qualsiasi elemento esistente location nel file Web.config . Esiste già un location elemento che specifica le regole di autorizzazione per la pagina Update Credits .) Quando si testa il sito di produzione dopo la distribuzione, si verificherà che questa regola di autorizzazione sia valida.
Non è necessario limitare l'accesso al log degli errori nell'ambiente di test, quindi non è necessario aggiungere questo codice al file Web.Test.config .
Nota
Nota sulla sicurezza Non visualizzare mai i dettagli degli errori al pubblico in un'applicazione di produzione o archiviare tali informazioni in una posizione pubblica. Gli utenti malintenzionati possono usare le informazioni sugli errori per individuare le vulnerabilità in un sito. Se si usa ELMAH nella propria applicazione, assicurarsi di esaminare i modi in cui ELMAH può essere configurato per ridurre al minimo i rischi per la sicurezza. L'esempio ELMAH in questa esercitazione non deve essere considerato una configurazione consigliata. È un esempio scelto per illustrare come gestire una cartella in cui l'applicazione deve essere in grado di creare file.
Impostazione di un indicatore di ambiente
Uno scenario comune consiste nell'avere impostazioni del file Web.config che devono essere diverse in ogni ambiente in cui viene eseguita la distribuzione. Ad esempio, un'applicazione che chiama un servizio WCF potrebbe richiedere un endpoint diverso in ambienti di test e produzione. L'applicazione Contoso University include anche un'impostazione di questo tipo. Questa impostazione controlla un indicatore visibile nelle pagine di un sito che indica l'ambiente in cui ci si trova, ad esempio sviluppo, test o produzione. Il valore dell'impostazione determina se l'applicazione aggiungerà "(Dev)" o "(Test)" all'intestazione principale nella pagina master Site.Master :
L'indicatore di ambiente viene omesso quando l'applicazione è in esecuzione nell'ambiente di produzione.
Le pagine Web di Contoso University leggono un valore impostato nel appSettings file Web.config per determinare l'ambiente in cui è in esecuzione l'applicazione:
<appSettings>
<add key="Environment" value="Dev" />
</appSettings>
Il valore deve essere "Test" nell'ambiente di test e "Prod" nell'ambiente di produzione.
Aprire Web.Production.config e aggiungere un appSettings elemento immediatamente prima del tag di apertura dell'elemento location aggiunto in precedenza:
<appSettings>
<add key="Environment" value="Prod" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>
Il xdt:Transform valore dell'attributo "SetAttributes" indica che lo scopo di questa trasformazione è modificare i valori di attributo di un elemento esistente nel file Web.config . Il xdt:Locator valore dell'attributo "Match(key)" indica che l'elemento da modificare è quello il cui key attributo corrisponde all'attributo key specificato qui. L'unico attributo dell'elemento add è valuee questo è ciò che verrà modificato nel file Web.config distribuito. Questo codice determina l'impostazione dell'attributo dell'elemento appSettings Environment su "Prod" nel file Web.config distribuito nell'ambiente di produzione.value
Applicare quindi la stessa modifica al file Web.Test.config , ad eccezione di impostare su value "Test" anziché su "Prod". Al termine, la appSettings sezione in Web.Test.config sarà simile all'esempio seguente:
<appSettings>
<add key="Environment" value="Test" xdt:Transform="SetAttributes" xdt:Locator="Match(key)"/>
</appSettings>
Disabilitazione della modalità di debug
Per una build di versione, non si vuole abilitare il debug indipendentemente dall'ambiente in cui si esegue la distribuzione. Per impostazione predefinita, il file di trasformazione Web.Release.config viene creato automaticamente con codice che rimuove l'attributo debug dall'elemento compilation :
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>
L'attributo Transform fa sì che l'attributo debug venga omesso dal file Web.config distribuito ogni volta che si distribuisce una build di rilascio.
Questa stessa trasformazione si trova nei file di trasformazione Test e Produzione perché sono stati creati copiando il file di trasformazione Versione. Non è necessario duplicarlo, quindi aprire ognuno di questi file, rimuovere l'elemento di compilazione e salvare e chiudere ogni file.
Impostazione delle stringhe di connessione
Nella maggior parte dei casi non è necessario configurare le trasformazioni stringa di connessione, perché è possibile specificare stringa di connessione nel profilo di pubblicazione. Tuttavia, si verifica un'eccezione quando si distribuisce un database di SQL Server Compact e si usa Migrazioni Code First di Entity Framework per aggiornare il database nel server di destinazione. Per questo scenario, è necessario specificare un stringa di connessione aggiuntivo che verrà usato nel server per aggiornare lo schema del database. Per configurare questa trasformazione, aggiungere un elemento connectionStrings> immediatamente dopo il tag di configurazione> di apertura <nei file di trasformazione Web.Test.config e Web.Production.config:<
<connectionStrings>
<add name="SchoolContext_DatabasePublish" connectionString="Data Source=|DataDirectory|School-Prod.sdf" providerName="System.Data.SqlServerCe.4.0" xdt:Transform="Insert"/>
</connectionStrings>
L'attributo Transform specifica che questo stringa di connessione verrà aggiunto all'elemento connectionStrings nel file Web.config distribuito. Il processo di pubblicazione crea automaticamente questo stringa di connessione aggiuntivo se non esiste, ma per impostazione predefinita l'attributo providerName viene impostato su System.Data.SqlClient, che non funziona per SQL Server Compact. Aggiungendo manualmente il stringa di connessione, si impedisce al processo di distribuzione di creare un elemento stringa di connessione con il nome del provider errato.
Sono state ora specificate tutte le trasformazioni Web.config necessarie per distribuire l'applicazione Contoso University per testare e produzione. Nell'esercitazione seguente si esamineranno le attività di configurazione della distribuzione che richiedono l'impostazione delle proprietà del progetto.
Ulteriori informazioni
Per altre informazioni sugli argomenti trattati in questa esercitazione, vedere lo scenario di trasformazione Web.config in ASP.NET Mappa contenuto distribuzione.