Gestione di file Web.Config complessi tra ambienti di distribuzione

Qualcuno sa di buoni strumenti / utilità per la gestione Web.Config file Web.Config tra diversi ambienti di compilazione / distribuzione?

Ad esempio, ho un progetto WCF che in sviluppo non voglio abilitare SSL, ma lo voglio abilitato in produzione. Desidero impostazioni di registrazione diverse, stringhe di connessione DB diverse, gestione degli errori diversa, percorsi di file diversi … Persino alcuni diversi binding di Unity framework (wire up mock per le unit test invece degli oggetti reali per la distribuzione).

Mantenere singole copie di Web.Config è un Web.Config , perché aggiungere un nuovo servizio Web significa modificare più file e mantenerli sincronizzati.

Ho anche notato che se muck con Web.Config troppo a mano, Visual Studio si strozzerà se si tenta di utilizzare la procedura guidata “aggiungi elemento” per, ad esempio, aggiungere un nuovo servizio Web per WCF, dal momento che deve modificare il Web.Config per aggiungere l’endpoint, e non può più analizzarlo. Quindi devo fare attenzione a non invalidare il Web.Config esistente.

Ho anche pensato di usare solo alcune Web.Config per fare rimpiazzi e semplicemente build un nuovo Web.Config in un comando di pre-compilazione. Sembra l’opzione migliore finora …

Altre idee? Sembra che questo dovrebbe essere un problema molto comune, dal momento che Web.Config probabilmente non dovrebbe mai essere lo stesso tra le distribuzioni di sviluppo e di produzione.


Aggiornare:

Ho deciso di scrivere un’app per console rapida che prendesse tutti i file xml in una determinata directory e li unisse in uno solo e includesse solo determinati file in base al nome.

Quindi posso creare una directory:

WebConfig_All

   ...   ...   

connectionStrings_Debug

      

connectionStrings_Release

      

Quindi esegui il mio strumento da riga di comando e passa la configurazione (Debug, Release, custom …) e unirà tutti i file che terminano in _All" or _ `.

Così ora ho l’80% del mio Web.Config in un singolo file WebConfig_All e il 20% di materiale personalizzato in file separati per configurazione di build. Posso quindi eseguire il mio strumento da riga di comando come attività pre-compilazione in VisualStudio, o da NAnt, o ovunque io voglia …

Ho anche realizzato la mia XML merge logic abbastanza bene da gestire cose come:

      

fondersi con

       

risultati in:

        

Guardando bene finora … 🙂


Azione supplementare:

Questo argomento è un po ‘vecchio ora, quindi volevo sottolineare che VisualStudio 2010 ha una funzione per realizzare le trasformazioni web.config integrate: http://msdn.microsoft.com/en-us/vstudio/Video/ff801895

Ovviamente nella tipica moda di Microsoft implementare solo qualsiasi funzionalità al 50% del modo, funziona solo per i progetti Web che utilizzano la distribuzione Web. C’è un plugin per abilitare le trasformazioni in altri progetti, che si trovano qui: http://www.hanselman.com/blog/SlowCheetahWebconfigTransformationSyntaxNowGeneralizedForAnyXMLConfigurationFile.aspx

Puoi anche usare uno strumento come BuildMaster per gestire i file di configurazione (insieme a build, test, script DB, ecc …)

Abbiamo suddiviso tutte le impostazioni specifiche della regione nel loro file di configurazione. Sotto la radice dell’app Web creiamo una cartella di configurazione e posizioniamo lì le impostazioni specifiche della regione. Quindi qualsiasi file vivrà sotto la radice della configurazione verrà catturato.

il nostro web.config ha un aspetto simile a:

 . . .        . . . 

Quindi, se stiamo implementando nell’area di rilascio, lo strumento di compilazione avrà solo un’azione per sostituire i file nella root di config con i file dalla cartella della regione appropriata. La struttura del file assomiglia a qualcosa:

AGGIUNTA: Ecco come appare la struttura di controllo del codice sorgente, l’app distribuita avrebbe solo la directory di configurazione senza sottocartelle o corso

 \Root web.config \Config appsettings.config services.config logging.config \release appsettings.config services.config logging.config \debug appsettings.config services.config logging.config 

È abbastanza pulito e supportato da qualsiasi strumento di compilazione automatico (copia / sostituzione di file). L’aspetto positivo è che gli sviluppatori possono creare diversi sapori e tenerli sotto il controllo del codice sorgente senza influenzare le “vere” configurazioni.

Vuoi l’attività XmlMassUpdate in MSBuildCommunityTasks (fa ciò che stai cercando di fare con l’app per console xml)

http://msbuildtasks.tigris.org/

usalo in questo modo

   

Potresti usare Build Events per gestire le tue configurazioni web. Hanselman ha un buon articolo a riguardo.

Fondamentalmente hai tutti i tuoi diversi web.configs nella soluzione che poi crei (alcuni) nuovi tipi di build. A seconda del tipo di build che si esegue, un web.config viene copiato su quello di riferimento!

Uso il metodo spiegato da Scott Hanselman (lo spiega molto meglio di quello che posso riprodurre così seguo il link :)) Ha funzionato bene per me …

Io uso questo strumento: xmlpreprocess

gestiamo file di “proprietà” separati per ogni ambiente che vengono uniti dallo script di distribuzione.

Mi piace utilizzare un’attività di compilazione per automatizzare la modifica del file di configurazione per l’ambiente desiderato.

Utilizziamo i tag nei nostri file di configurazione, che vengono sostituiti al momento della compilazione per riflettere l’ambiente di distribuzione previsto. Sono stato ispirato dal blog Lavablast

È bello avere solo un file di configurazione del modello da gestire.

Lo svantaggio è che non puoi facilmente avere “sezioni” personalizzate.

Vecchia domanda, ma dal momento che sta avendo un alto rango nella ricerca di Google, ho pensato che fosse una buona idea aggiungere la syntax di trasformazione web.config , che era disponibile dal VS2010 . Con questo strumento, puoi avere diversi file web.config per differenti build (Debug / Release)

Ecco un breve riassunto su come avere due stringhe di connessioni: una per lo sviluppo (modalità Debug) e una per la produzione (modalità di rilascio):

1- Impostare la stringa di connessione di sviluppo nel file web.config. Dovrebbe assomigliare a questo:

     

2- Espandi il tuo file web.config e apri web.release.config

web.config

3- Utilizzare la funzione Replace per sostituire la stringa di connessione con quella desiderata per la produzione. È ansible utilizzare l’attributo xdt:Locator="Match(name)" per abbinarlo al nome della stringa di connessione (myConnectionString) in questo esempio:

    

4- Visualizzare in anteprima la trasformazione del file web.config che verrà utilizzato durante la creazione della versione facendo clic con il pulsante destro del mouse sul file web.release.config e scegliendo Anteprima trasformazione .

inserisci la descrizione dell'immagine qui

Ho tradizionalmente usato più web.configs come hai menzionato. Può essere un dolore, ma è mitigato da strumenti di confronto di file come BeyoneComapare2 o KDIff …

Fastidio:

Ho citato la mia piccola app per la linea cmd per unire documenti XML nel mio primo aggiornamento … Beh, per farlo uso semplicemente XmlDocument, e alla fine semplicemente .Save () su un FileStream.

Sfortunatamente, i nodes non sono realmente in un ordine particolare, e apparentemente, .NET richiede che l’elemento sia il 1 ° figlio del documento.

Pensavo che tutti questi strumenti fantasiosi avrebbero dovuto semplificare la programmazione della vita?

I miei due modi preferiti di affrontare questo sono:

A. Mantenere le impostazioni sul computer di destinazione *: in Azure, ad esempio, è ansible configurare le impostazioni dell’applicazione e le stringhe di connessione che sovrascriveranno i valori in web.config. (* – o definizione della macchina di destinazione se la configurazione dell’infrastruttura è dynamic).

B. Realizzare lo strumento di compilazione / distribuzione (TeamCity, Octopus Deploy, ecc., VS Team Services) inietti i valori specifici dell’ambiente come parte della compilazione e / o della distribuzione. I moderni strumenti supportano la crittografia delle impostazioni sensibili.