Utilizzo di Web.config diversi nell'ambiente di sviluppo e produzione

Devo utilizzare una stringa di connessione al database e un indirizzo server SMTP diversi nella mia applicazione ASP.NET a seconda che venga eseguita in ambiente di sviluppo o produzione.

L'applicazione legge le impostazioni dal file Web.config tramite la proprietà WebConfigurationManager.AppSettings .

Uso il comando Build / Publish per distribuire l'applicazione sul server di produzione tramite FTP e quindi sostituire manualmente Web.config remoto con uno corretto.

È possibile in qualche modo semplificare il processo di distribuzione? Grazie!

In Visual Studio 2010 e versioni successive, ora hai la possibilità di applicare una trasformazione al tuo web.config a seconda della configurazione della build.

Quando si crea un web.config, è possibile espandere il file in Esplora soluzioni e verranno visualizzati due file:

• Web.Debug.Config
• Web.Release.Config

Contengono un codice di trasformazione che può essere utilizzato per

• Cambia la stringa di connessione
• Rimuovere la traccia e le impostazioni di debug
• Registrare le pagine di errore

Vedere Sintassi della trasformazione Web.config per la distribuzione di progetti di applicazioni Web su MSDN per ulteriori informazioni.

È anche possibile, sebbene ufficialmente non supportato, applicare lo stesso tipo di trasformazione a un app.configfile di un'applicazione non web . Vedi il blog di Phil Bolduc su come modificare il file di progetto per aggiungere una nuova attività a msbuild.

Questa è una richiesta di lunga durata sull'Uservoice di Visual Studio .

È disponibile un'estensione per Visual Studio 2010 e versioni successive, " SlowCheetah " , per la creazione della trasformazione per qualsiasi file di configurazione. A partire da Visual Studio 2017.3, SlowCheetah è stato integrato nell'IDE e la base di codice è gestita da Microsoft. Questa nuova versione supporta anche la trasformazione JSON.

Il <appSettings>tag in web.config supporta un attributo di file che caricherà una configurazione esterna con il proprio set di chiavi / valori. Queste sovrascriveranno tutte le impostazioni che hai nel tuo web.config o le aggiungeranno.

Ne approfittiamo modificando il nostro web.config al momento dell'installazione con un attributo di file che corrisponde all'ambiente in cui il sito viene installato. Lo facciamo con un interruttore sul nostro programma di installazione.

per esempio;

<appSettings file=".\EnvironmentSpecificConfigurations\dev.config">

<appSettings file=".\EnvironmentSpecificConfigurations\qa.config">

<appSettings file=".\EnvironmentSpecificConfigurations\production.config">

Nota:

• Le modifiche al .config specificato dall'attributo non attiveranno un riavvio del processo di lavoro asp.net

Hai cercato progetti di distribuzione Web?

http://www.microsoft.com/downloads/details.aspx?FamilyId=0AA30AE8-C73B-4BDD-BB1B-FE697256C459&displaylang=en

Esiste anche una versione per VS2005, se non sei del 2008.

Vorrei sapere anche io. Questo aiuta a isolare il problema per me

<connectionStrings configSource = "connectionStrings.config" />

Tengo quindi un connectionStrings.config e un "{host} connectionStrings.config". È ancora un problema, ma se lo fai per sezioni diverse nei due ambienti, puoi distribuire e versioni lo stesso web.config.

(E non uso VS, btw.)

Uso uno script di build NAnt per distribuire nei miei diversi ambienti. Devo modificare i miei file di configurazione tramite XPath a seconda di dove vengono distribuiti e quindi li inserisce automaticamente in quell'ambiente usando Beyond Compare .

Richiede un minuto o due per l'installazione, ma devi farlo una sola volta. Quindi i file batch prendono il sopravvento mentre vado a prendere un'altra tazza di caffè. :)

Ecco un articolo che ho trovato su di esso.

In un progetto in cui avevamo 4 ambienti (sviluppo, test, gestione temporanea e produzione) abbiamo sviluppato un sistema in cui l'applicazione ha selezionato la configurazione appropriata in base al nome della macchina in cui è stata distribuita.

Questo ha funzionato per noi perché:

• gli amministratori potevano distribuire applicazioni senza coinvolgere gli sviluppatori (un requisito) e senza dover giocherellare con i file di configurazione (che odiavano);
• i nomi delle macchine hanno aderito a una convenzione. Abbiamo abbinato i nomi usando un'espressione regolare e distribuito su più macchine in un ambiente; e
• abbiamo usato la sicurezza integrata per le stringhe di connessione. Ciò significa che potremmo conservare i nomi degli account nei nostri file di configurazione in fase di progettazione senza rivelare alcuna password.

In questo caso ha funzionato bene per noi, ma probabilmente non funzionerebbe ovunque.

L'editor di configurazione di Enterprise Library può aiutarti a farlo. Ti consente di creare un file di configurazione di base e quindi delta per ogni ambiente. È quindi possibile unire la configurazione di base e il delta per creare un web.config specifico per l'ambiente. Dai un'occhiata alle informazioni qui che ti guidano meglio di me.

Potresti anche renderlo un passaggio post-build. Installa una nuova configurazione che è "Distribuisci" oltre a Debug e Release, quindi esegui la copia del passaggio post-build sul web.config corretto.

Utilizziamo build automatizzate per tutti i nostri progetti e con questi lo script di build aggiorna il file web.config per puntare alla posizione corretta. Ma questo non ti aiuterà se stai facendo tutto da VS.

Questo è uno dei grandi vantaggi dell'utilizzo di machine.config. Nel mio ultimo lavoro, abbiamo avuto ambienti di sviluppo, test e produzione. Potremmo usare machine.config per cose come le stringhe di connessione (alla macchina SQL dev / test / prod appropriata).

Questa potrebbe non essere una soluzione per te se non hai accesso all'attuale macchina di produzione (come se stessi utilizzando una società di hosting su un host condiviso).

Puoi anche usare l'estensione "Configuration Transform" funziona come "SlowCheetah",