Differenziert man web.config zwischen Entwickler, Inszenierung und Produktionsumgebungen

StackOverflow https://stackoverflow.com/questions/1406157

Frage

Wer noch keine guten Tipps auf Unterschiede in web.config Einstellungen zwischen Umgebungen Handhabung? Ich habe als einen ‚config‘ Ordner in unserem Quellkontrollsystem, aber außerhalb der Web-Hierarchie zu schaffen, und mit dem Bereitstellungsprozess der entsprechenden Konfigurationsdateien kopieren (web.dev.config, web.staging.config, web.production.config ) in den Web-Ordner beim Entfalten. Ich habe auch Beiträge, wie gesehen programmatisch die Konfigurationseinstellungen ändern (WCF-Endpunkte, Verbindungszeichenfolgen, usw.), wenn die Anwendung gestartet wird.

Was hier Best Practices angesehen, und welche Erfahrungen haben mit diesen oder anderen Ansätzen jeder hatte?

Update September 2010

Es ist erwähnenswert, dass Visual Studio 2010 diese Fähigkeit über web.config verwandelt . Wenn Sie die Build-Konfigurationsmanager verwenden (Build | Configuration Manager ...) verschiedene Konfigurationen für Ihr Projekt (sagen wir, Debug, Dev, Staging und Release) zu erstellen, fügt VS Web * Konfigurationsdateien zur Lösung... Der Standard web.config enthält Baseline-Einstellungen, die Sie für das Debuggen verwenden werden. web.release.config, web.staging.config usw. enthalten XSLT-Transformationen, die angewendet werden, wenn Sie Ihr Projekt auf der Basis der aktiven Build-Konfiguration veröffentlichen.

War es hilfreich?

Lösung

Mit dem neuen VS Sie Web-Config-Transformationen verwenden können.

Lesen Sie mehr hier: http://msdn.microsoft.com/en- us / library / dd465326.aspx

Andere Tipps

Mein Ansatz ist es, mehrere Konfigurationsdateien zu haben. Ich habe alle Agnostiker Sachen Umgebung (das heißt nicht, ob Entwickler, Inszenierung keine Rolle, oder Produktion) in der Datei web.config. Alles, was für die Umwelt spezifisch ist (das heißt Datenbankverbindung Info, Anmeldung, Debug-Einstellungen, etc.) I in eine local.config Datei spezifisch für die Umwelt setzen. Sie können dann schließen die local.config Einstellungen in der web.config mit configSource ( http://weblogs.asp.net/fmarguerie/archive/2007/04/26/using-configsource-to-split-configuration-files.aspx )

Web.config kann dann in der Quellcodeverwaltung überprüft werden. Nicht in den local.config Dateien überprüfen -., Dass Kräfte Sie die richtigen in Ihrem deploy Skripte bereitstellen

Ich benutze CruiseControl.NET/NAnt und NAnt hat eine XMLPoke Aufgabe, die Sie in gehen können, wie Sie bauen und verändern XPath-Abfragen jede Konfigurationseinstellung verwendet wird.

So in jedem meiner Build-Ziele (DEV, UAT, INSZENIERUNG etc) stelle ich eine Reihe von Eigenschaften und dann die Ziel Master Build aufrufen. Das Master-Build-Ziel nimmt die Werte aller Eigenschaften und XMLPokes sie in die config und baut.

Eine Methode, die ich gesehen habe und verwendet ist, wo Sie Setup-Schlüssel in Ihrem web.config die Computer nach dem Namen zu unterscheiden.

So zum Beispiel: 

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

Offensichtlich COMP1, compdb1 sind die eigentlichen Computernamen.

Sie würden dann Setup so etwas wie: 

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

In Ihrem Code müssen Sie überprüfen, welche Umgebung die Anwendung läuft auf und dann die entsprechende Taste erhalten, so zum Beispiel. 

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;
}

Es gibt einen Projekttyp namens Web Deployment-Projekt , frei von Microsoft zur Verfügung, die es Ihnen ermöglichen, genau das zu tun. Sie können Teile Ihrer web.config, abhängig von Ihrer Lösungskonfiguration ersetzen (Debug, Release etc.) Wir verwenden, dass ein Jahr länger als und es funktioniert gut. Es ist verfügbar für VS2005 und VS2008.

Hope dies helfen wird,

Während einige der anderen Antworten können besser geeignet sein, werde ich nur hinzufügen, dass Matt Berseth rollte seine eigene Methode im Jahr 2007 zurück ...

Insgesamt hält er alle Werte, die zwischen Umgebungen in einer proprietären Textdatei und verwendet ein benutzerdefiniertes Werkzeug während des Erstellungsprozesses variieren die Werte in die CONFIG-Dateien zusammenführen.

In einem Kommentar zu diesem Beitrag Doron Yaacoby auch kommentiert:

  

"Es ist eine Aufgabe in MSBuild Gemeinschaft   Aufgaben, die dies erreichen können (und mehr)   für Sie, die aufgerufen wird,   XmlMassUpdate. Ive darüber in meinem Blog geschrieben "

Hier ist, wie verschiedene Konfigurationen hinzufügen, die für Ihre Bereitstellung Umgebungen in VS2012 angepasst werden kann

  1. der rechten Maustaste auf die Lösung und wählen Sie Konfigurationsmanager
  2. Klicken Sie auf die Schaltfläche Configuration Manager
  3. Unter der Konfiguration Spaltenauswahlkombinationsfeld gegen das Projekt dass Sie eine Konfiguration und wählen
    4. hinzufügen möchten
  4. Erstellen Sie eine neue Konfiguration mit einem Namen wie TEST und Kopie-Einstellungen von Release und prüfen Sie die Checkbox Erstellen neuer Lösungskonfigurationen
  5. die rechte Maustaste auf der Web.config
  6. Add Config-Transformation
  7. Dann erhalten Sie eine zusätzliche web.config Eg web.TEST.config

Danach müssen Sie web.TEST.config mit einigen Transformationen speziell für Ihre Testumgebung

ändern

Sie müssen sich für eine Umgebung installieren, nicht BUILD für einen. In der realen Welt, müssen Sie in prod installieren, was in QA getestet wurde, erlaubt kein Wiederaufbau. Zumindest in meiner Welt, die der Fall ist. 

 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/";
        }
    }

}

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top