Distribuzione di un'applicazione Web ASP.NET con SQL Server Compact tramite Visual Studio o Visual Web Developer: trasformazioni Web.Config file - 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 pubblicazione Web. Per un'introduzione alla serie, vedere la prima esercitazione nella serie.

Per un'esercitazione che illustra le funzionalità di distribuzione introdotte dopo la versione RC di Visual Studio 2012, viene illustrato come distribuire edizioni SQL Server diverse da SQL Server Compact e viene illustrato come eseguire la distribuzione in Servizio app di Azure 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 deve essere diverso quando l'applicazione viene distribuita. L'automazione del processo di apportare queste modifiche impedisce di dover eseguire manualmente le modifiche ogni volta che si distribuisce, che sarebbe noioso e soggetto a errori.

Promemoria: se viene visualizzato un messaggio di errore o qualcosa che non funziona durante l'esercitazione, assicurarsi di controllare la pagina di risoluzione dei problemi.

trasformazioni Web.config rispetto ai parametri di distribuzione Web

Esistono due modi per automatizzare il processo di modifica delle impostazioni dei file Web.config : trasformazioniWeb.config e parametri distribuzione Web. Un file di trasformazioneWeb.config contiene markup XML che specifica come modificare il file diWeb.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 e è possibile creare configurazioni di compilazione personalizzate. Un profilo di pubblicazione corrisponde in genere a un ambiente di destinazione. Altre informazioni sulla pubblicazione dei profili nell'esercitazione Distribuzione in IIS come ambiente di test .

I parametri Di distribuzione Web possono essere usati per specificare molti tipi di impostazioni diversi che devono essere configurati durante la distribuzione, incluse le impostazioni disponibili nei file di Web.config . Quando viene usato per specificare Web.config modifiche ai file, i parametri 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 in produzione e tale persona deve essere in grado di immettere stringhe di connessione o password che non si conosce.

Per lo scenario illustrato in questa esercitazione, si conosce tutto ciò che deve essere eseguito nel file Web.config , quindi non è necessario usare i parametri Distribuzione Web. Verranno configurate alcune trasformazioni diverse a seconda della configurazione di compilazione usata e alcune diverse 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 due file di trasformazione più, per configurare le modifiche correlate alla destinazione di 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 si creeranno profili di pubblicazione denominati Test e Production, quindi è necessario 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 in 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 possono essere distribuiti automaticamente.

È ora possibile immettere 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 degli errori e la segnalazione. 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 di errore, modificare temporaneamente l'attributo mode dell'elemento customErrors da "RemoteOnly" a "On" ed eseguire l'applicazione da Visual Studio. Causa un errore richiedendo un URL non valido, ad esempio Studentsxxx.aspx. Anziché una pagina di errore "page not found" generata da IIS, viene visualizzata la pagina GenericErrorPage.aspx .

Per visualizzare il log degli errori, sostituire tutto nell'URL dopo il numero di porta con elmah.axd (ad esempio nella schermata http://localhost:51130/elmah.axd) e premere INVIO:

Non dimenticare di impostare di nuovo l'elemento customErrors in modalità "RemoteOnly" al termine.

Nel computer di sviluppo è utile consentire l'accesso gratuito alla pagina del log degli errori, ma in produzione che sarebbe un rischio di 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 diWeb.Production.config .

Aprire Web.Production.config e aggiungere un nuovo location elemento immediatamente dopo il tag di apertura configuration , come illustrato qui. Assicurarsi di aggiungere solo l'elemento e non il location 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" causa l'aggiunta di questo location elemento come elemento di pari livello a qualsiasi elemento esistente location nel file Web.config . È già presente un location elemento che specifica le regole di autorizzazione per la pagina Aggiorna crediti . Quando si testa il sito di produzione dopo la distribuzione, si verificherà che questa regola di autorizzazione sia effettiva.

Non è necessario limitare l'accesso al log degli errori nell'ambiente di test, quindi non è necessario aggiungere questo codice al file diWeb.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 analizzare i modi in cui ELMAH può essere configurato per ridurre al minimo i rischi di sicurezza. L'esempio ELMAH in questa esercitazione non deve essere considerato una configurazione consigliata. Si tratta di 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 fileWeb.config che devono essere diverse in ogni ambiente distribuito. Ad esempio, un'applicazione che chiama un servizio WCF potrebbe richiedere un endpoint diverso negli 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 in quale ambiente 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 in produzione.

Le pagine Web di Contoso University leggeno un valore impostato appSettings nel 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 consiste nel modificare i valori dell'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 è , ed è valueciò che verrà modificato nel file di Web.config distribuito. Questo codice determina l'impostazione dell'attributo dell'elemento value su "Prod" nel file Web.config distribuito nell'ambiente EnvironmentappSettings di produzione.

Applicare quindi la stessa modifica al file Web.Test.config , ad eccezione di impostarla value su "Test" anziché su "Prod". Al termine, la sezione in Web.Test.config sarà simile all'esempio appSettings 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 sta distribuendo. Per impostazione predefinita, il file di trasformazioneWeb.Release.config viene creato automaticamente con il codice che rimuove l'attributo dall'elemento debugcompilation :

<system.web>
  <compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>

L'attributo Transform determina l'omesso dall' debugWeb.config file distribuito ogni volta che si distribuisce una compilazione release.

Questa stessa trasformazione si trova nei file di trasformazione test e di produzione perché sono stati creati copiando il file di trasformazione release. Non è necessario duplicato, 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 delle stringhe di connessione, perché è possibile specificare le stringhe di connessione nel profilo di pubblicazione. Tuttavia, si verifica un'eccezione quando si distribuisce un database 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 una stringa di connessione aggiuntiva che verrà usata nel server per aggiornare lo schema del database. Per configurare questa trasformazione, aggiungere un <elemento connectionStrings> immediatamente dopo l'apertura <del tag di configurazione> nella Web.Test.config e nei file di trasformazione 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 questa stringa di connessione verrà aggiunta all'elemento connectionStrings nel file di Web.config distribuito. Il processo di pubblicazione crea automaticamente questa stringa di connessione aggiuntiva 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 la stringa di connessione, si mantiene il processo di distribuzione dalla creazione di 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 produrre. Nell'esercitazione seguente si esamineranno le attività di configurazione della distribuzione che richiedono l'impostazione delle proprietà del progetto.

Altre informazioni

Per altre informazioni sugli argomenti trattati in questa esercitazione, vedere lo scenario di trasformazione Web.config in ASP.NET Mappa contenuto distribuzione.

IndietroAvanti