Differenziazione web.config tra ambienti di sviluppo, gestione temporanea e produzione

Question

Qualcuno ha qualche buon consiglio sulla gestione delle differenze nelle impostazioni web.config tra ambienti? Ho preso in considerazione la possibilità di creare una cartella 'config' nel nostro sistema di controllo del codice sorgente ma al di fuori della gerarchia Web e di fare in modo che il processo di distribuzione copi i file di configurazione appropriati (web.dev.config, web.staging.config, web.production.config ) nella cartella Web al momento della distribuzione. Ho anche visto post su come modificare a livello di programmazione le impostazioni di configurazione (endpoint WCF, stringhe di connessione, ecc.) All'avvio dell'app.

Quali sono le migliori pratiche considerate qui e quali esperienze hanno avuto tutti con questi o altri approcci?

Aggiornamento settembre 2010

Vale la pena notare che Visual Studio 2010 aggiunge questa capacità tramite trasformazioni web.config . Quando si utilizza il gestore configurazione build (Build | Configuration Manager ...) per creare diverse configurazioni per il proprio progetto (ad esempio Debug, Dev, Staging e Release), VS aggiunge i file web. *. Config alla soluzione. Il web.config predefinito contiene le impostazioni di base che utilizzerai per il debug. web.release.config, web.staging.config, ecc. contengono trasformazioni XSLT che verranno applicate ogni volta che pubblichi il tuo progetto in base alla configurazione di build attiva.

Answer 1

Con il nuovo VS puoi usare le trasformazioni di configurazione web.

Ulteriori informazioni qui: http://msdn.microsoft.com/en- us / library / dd465326.aspx

Answer 2

Il mio approccio è stato quello di avere più file di configurazione. Metto tutte le cose agnostiche nell'ambiente (cioè non importa se dev, stadiazione o produzione) nel file web.config. Tutto ciò che è specifico per l'ambiente (ad es. Informazioni sulla connessione al database, registrazione, impostazioni di debug, ecc.) Ho inserito un file local.config specifico per l'ambiente. È quindi possibile includere le impostazioni local.config in web.config utilizzando configSource ( http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx )

Web.config può quindi essere verificato nel controllo del codice sorgente. Non controllare nei file local.config - ciò ti costringe a distribuire quello corretto nei tuoi script di distribuzione.

Answer 3

Uso CruiseControl.NET/NAnt e NAnt ha un'attività XMLPoke che ti consente di accedere mentre stai costruendo e modificare qualsiasi impostazione di configurazione usando le query XPath.

Quindi in ciascuno dei miei target di build (DEV, UAT, STAGING ecc.) ho impostato un gruppo di proprietà e quindi ho chiamato il target di build principale. Il target di build principale prende i valori di tutte le proprietà e XML li inserisce nella configurazione e nelle build.

Answer 4

Un metodo che ho visto e usato è quello di impostare le chiavi all'interno del tuo web.config per differenziare i computer per nome.

Ad esempio:

<add key="comp1.Environment"       value="DEV"/>
<add key="compdb1.Environment"     value="PROD"/>
<add key="compstage.Environment"    value="STAGE"/>

Ovviamente comp1, compdb1 sono i nomi reali dei computer.

Dovresti quindi impostare qualcosa come:

<add key="KeyName,DEV"   value="DevEnvironmentValue"/>

Nel tuo codice dovrai controllare su quale ambiente l'applicazione è in esecuzione e quindi ottenere la chiave appropriata, quindi per esempio.

private string GetKeyValue() {
    string machineName  = String.Concat(System.Environment.MachineName, ".Environment");
    string environment  = ConfigurationManager.AppSettings[machineName];
    string key          = String.Concat("KeyName", ",", environment);
    string keyValue       = ConfigurationManager.AppSettings[key];

    return keyValue;
}

Answer 5

Esiste un tipo di progetto denominato Progetto di distribuzione Web , disponibile gratuitamente da Microsoft che ti consente di fare esattamente questo. Puoi sostituire sezioni del tuo web.config, a seconda della configurazione della tua soluzione (debug, release ecc.). Lo usiamo da più di un anno e funziona bene. È disponibile per VS2005 e VS2008.

Spero che questo possa aiutare

Answer 6

Mentre alcune delle altre risposte potrebbero essere più adatte, aggiungerò semplicemente Matt Berseth ha adottato il suo metodo nel 2007 ...

In breve, mantiene tutti i valori che variano tra gli ambienti in un file di testo proprietario e usa uno strumento personalizzato durante il processo di compilazione per unire i valori nei file .config.

In un commento su quel post anche Doron Yaacoby commenta:

  

" esiste un'attività nella Community di MSBuild   Compiti che possono raggiungere questo (e altro)   per te, che si chiama   XmlMassUpdate. Ne ho scritto nel mio blog "

Answer 7

Ecco come aggiungere diverse configurazioni che possono essere personalizzate per gli ambienti di distribuzione in VS2012

1. Fare clic con il tasto destro del mouse sulla soluzione e selezionare Configuration Manager
2. Fai clic sul pulsante Gestione configurazione
3. Nella colonna Configurazione selezionare la casella combinata rispetto al progetto a cui si desidera aggiungere una configurazione e selezionare
4. Crea una nuova configurazione con un nome come TEST e copia le impostazioni da Rilasciare e selezionare la casella di controllo Crea nuove configurazioni della soluzione
5. Fare clic con il tasto destro del mouse su Web.config
6. Aggiungi trasformazione configurazione
7. Quindi si ottiene un ulteriore web.config Ad esempio web.TEST.config

Successivamente, è necessario modificare web.TEST.config con alcune trasformazioni specifiche dell'ambiente TEST

Answer 8

È necessario INSTALLARE per un ambiente, non COSTRUIRE per uno. Nel mondo reale, devi installare in ciò che è stato testato nel QA, non è consentita la ricostruzione. Almeno nel mio mondo è così.

Answer 9

 Easy way to have that is having an Enumeration , then having a switch statement based on the server name ( if its stable name ) .  
 Call GetURIPath() where ever you require to fetch details , here I given the examples for url's used 


public class StaticData
{
    public enum enumEnvironment
    {
        envNONE = 0,
        envLOC = 1,
        envDEV = 2,
        envTEST = 3,
        envPROD = 4
    }
     private static enumEnvironment GetCurrentEnv()
    {
        if (ConfigurationManager.GetSection("DBSettingsGroup/DBSettings") == null && ConfigurationManager.GetSection("DBSettings") == null)
        {
            return enumEnvironment.envLOC;
        }
        else
        {
            NameValueCollection NVCollection = new NameValueCollection();
            NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettingsGroup/DBSettings");
            if(NVCollection == null)
            {
                NVCollection = (NameValueCollection)ConfigurationManager.GetSection("DBSettings");
            }

            string sEnv = NVCollection.GetValues("serverrole").ToString();

            switch (sEnv.ToUpper())
            {
                case "DEV-ISOLATED":
                    return enumEnvironment.envDEV;
                case "DEVELOPMENT":
                    return enumEnvironment.envDEV;
                case "TEST":
                    return enumEnvironment.envTEST;
                case "PRODUCTION":
                    return enumEnvironment.envPROD;
                default:
                    return enumEnvironment.envNONE;
            }
        }
    }
   public static string GetURIPath()
    {
        switch (GetCurrentEnv())
        {
            case enumEnvironment.envPROD:
                return "http://produrl/yourapp/api/";
            case enumEnvironment.envTEST:
                return "http://testurl/yourapp/api/";
            case enumEnvironment.envDEV:
                return "http://devurl/yourapp/api/";
            default:
                return "http://localhost/yourapp/api/";
        }
    }

}