Entwicklerspezifische app.config / web.config-Dateien in Visual Studio

Wir haben mehrere .NET-Projekte, in denen wir bestimmte Einstellungen in Konfigurationsdateien speichern.

Jetzt hat jeder Entwickler seine eigenen Konfigurationsdateien, die sich geringfügig unterscheiden (unterschiedliche Verbindungszeichenfolgen für die Verbindung zu lokalen Datenbanken, unterschiedliche WCF- Endpunkte usw.).

Im Moment neigen wir dazu, app / web.config-Dateien auszuchecken und sie an unsere Bedürfnisse anzupassen.

Dies führt zu vielen Problemen, da von Zeit zu Zeit jemand seine eigenen Einstellungen überprüft oder die benutzerdefinierte Konfiguration verliert, wenn er die neueste Version von TFS erhält .

Wie gehen Sie mit solchen Situationen um? Oder haben Sie dieses Problem überhaupt nicht?

Wir verwenden ein System, das mehrere der auf dieser Seite vorhandenen Antworten kombiniert und auf diesen Vorschlag von Scott Hanselman zurückgreift .

Kurz gesagt, wir haben eine gemeinsame app.config / web.config und die meisten spezifischen Einstellungen in einzelnen Dateien, wie in anderen Antworten hier vorgeschlagen. zB für unsere SMTP-Einstellungen enthält die app.config

<system.net>
  <mailSettings>
    <smtp configSource="config\smtp.config" />
  </mailSettings>
</system.net>

Diese Datei befindet sich in der Quellcodeverwaltung. Die einzelnen Dateien sind jedoch nicht wie folgt:

<?xml version="1.0" encoding="utf-8" ?>
<smtp deliveryMethod="Network">
  <network host="127.0.0.1" port="25" defaultCredentials="false" password="" userName ="" />
</smtp>

Hier endet die Geschichte allerdings nicht ganz. Was ist mit neuen Entwicklern oder einer neuen Quellinstallation? Der Großteil der Konfiguration befindet sich nicht mehr in der Quellcodeverwaltung, und es ist schwierig, alle benötigten .config-Dateien manuell zu erstellen. Ich bevorzuge eine Quelle, die zumindest sofort kompiliert werden kann.

Aus diesem Grund behalten wir eine Version der .config-Dateien in der Quellcodeverwaltung mit dem Namen .config.default- Dateien. Ein frischer Quellbaum sieht also so aus:

Für den Entwickler jedoch nicht wirklich von Nutzen, da sie für Visual Studio nur bedeutungslose Textdateien sind. Daher copy_default_config.batkümmert sich die Batch-Datei darum, einen ersten Satz von .config-Dateien aus den .config.default-Dateien zu erstellen:

@echo off
@REM Makes copies of all .default files without the .default extension, only if it doesn't already exist. Does the same recursively through all child folders.
for /r %%f in (*.default) do (
    if not exist "%%~pnf" (echo Copying %%~pnf.default to %%~pnf & copy "%%f" "%%~pnf" /y)
)
echo Done.

Das Skript kann sicher erneut ausgeführt werden, da Entwickler, die bereits über ihre .config-Dateien verfügen, diese nicht überschreiben lassen. Daher könnte man diese Batch-Datei möglicherweise als Pre-Build-Ereignis ausführen. Die Werte in den Standarddateien sind für eine Neuinstallation möglicherweise nicht genau korrekt, aber sie sind ein vernünftiger Ausgangspunkt.

Letztendlich hat jeder Entwickler einen Ordner mit Konfigurationsdateien, der ungefähr so ​​aussieht:

Es mag ein wenig verworren erscheinen, aber es ist definitiv dem Ärger der Entwickler vorzuziehen, die sich gegenseitig auf die Zehen treten.

Verwenden Sie in Ihrer Web.config die Quelle aus anderen Dateien

<configuration>
    <connectionStrings configSource="ConnectionStrings.config" />
...
</configuration>

Behalten Sie die web.config in der Versionskontrolle und tun Sie dies nicht für ConnectionStrings.config. Jetzt haben alle Entwickler eine Datei für die Verbindungszeichenfolge.

Sie können dies für alle Einstellungen tun, die lokal abhängig sind.

Hier eine Lösung für web.config-Dateien und Visual Studio 2010:

1) Bearbeiten Sie die .csproj-Datei Ihrer Webanwendung manuell, um ein AfterBuildZiel wie das folgende hinzuzufügen :

  <Project>
   ...
    <Target Name="AfterBuild">
      <Copy SourceFiles="web.config" DestinationFiles="obj\$(Configuration)\tempweb.config" />
      <TransformXml Source="obj\$(Configuration)\tempweb.config"
                  Transform="web.$(USERNAME).config"
                  Destination="obj\$(Configuration)\tempweb2.config" />
      <ReadLinesFromFile File="obj\$(Configuration)\tempweb2.config"><Output TaskParameter="Lines" ItemName="TransformedWebConfig"/></ReadLinesFromFile>
      <ReadLinesFromFile File="web.config"><Output TaskParameter="Lines" ItemName="UnTransformedWebConfig"/></ReadLinesFromFile>
      <Copy Condition=" @(UnTransformedWebConfig) != @(TransformedWebConfig) " SourceFiles="obj\$(Configuration)\tempweb2.config" DestinationFiles="web.config" OverwriteReadOnlyFiles="True" />
    </Target>
  </Project>

Dieses Ziel transformiert die Datei Web.config, die dem aktuell angemeldeten Entwickler entspricht - daher die $(USERNAME)Variable -, wobei die entsprechende Datei in 1) erstellt wird. Die lokale Web.config wird nur dann ersetzt, wenn sich der Inhalt bei jedem Build geändert hat (um einen Neustart zu vermeiden), auch wenn die lokale Web.config quellengesteuert ist. Aus diesem Grund ist die OverwriteReadOnlyFilesEinstellung auf True gesetzt. Dieser Punkt ist in der Tat fraglich.

2) Erstellen Sie eine Datei mit dem Namen Web.[developer windows login].configfür jeden Entwickler im Projekt. (In den folgenden Screenshots habe ich beispielsweise zwei Entwickler namens smo und smo2):

Diese Dateien (1 pro Entwickler) können / sollten quellengesteuert sein. Sie sollten nicht als abhängig von der Haupt-Web.config markiert werden, da wir sie einzeln auschecken möchten.

Jede dieser Dateien stellt eine Transformation dar, die auf die Hauptdatei Web.Config angewendet werden soll. Die Transformationssyntax wird hier beschrieben: Web.config-Transformationssyntax für die Bereitstellung von Webanwendungsprojekten . Wir verwenden diese coole XML-Dateitransformationsaufgabe, die mit Visual Studio ausgeliefert wird. Der Zweck dieser Aufgabe ist merge XML - Elemente und Attribute , anstatt die gesamte Datei zu überschreiben.

Hier ist beispielsweise ein Beispiel web.[dev login].config, das eine Verbindungszeichenfolge mit dem Namen "MyDB" unabhängig vom Rest der Datei "Web.config" ändert:

<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
    <connectionStrings>
      <add name="MyDB" 
        connectionString="Data Source=ReleaseSQLServer;Initial Catalog=MyReleaseDB;Integrated Security=True" 
        xdt:Transform="SetAttributes" xdt:Locator="Match(name)" />
    </connectionStrings>
</configuration>

Diese Lösung ist nicht perfekt, weil:

• Nach dem Erstellen haben Entwickler möglicherweise lokal eine andere Web.Config als im Quellcodeverwaltungssystem
• Möglicherweise müssen sie das lokale Schreiben erzwingen, wenn sie eine neue Web.Config vom Quellcodeverwaltungssystem erhalten
• Entwickler sollten nicht in der web.config auschecken. Es sollte nur wenigen Personen vorbehalten sein.

Zumindest müssen Sie jedoch nur eine eindeutige web.config-Hauptdatei sowie eine Transformationsdatei pro Entwickler verwalten.

Ein ähnlicher Ansatz könnte für App.config-Dateien (nicht für Webdateien) gewählt werden, aber ich habe nicht weiter darauf eingegangen.

Wir verwenden machine.config, um Unterschiede in web.config zwischen den Umgebungen zu vermeiden.

Wie wäre es, wenn Sie die Datei ignorieren, damit sie nie eingecheckt wird? Ich bin auf ein ähnliches Problem gestoßen und habe der Ignorierliste in Subversion web.config hinzugefügt.

In TFS ist es allerdings etwas schwieriger. In diesem Beitrag erfahren Sie, wie es geht.

Eine Möglichkeit, dies zu bewältigen, besteht darin, ein System mit Token zu haben und die Werte mithilfe eines Rake-Skripts zu ändern.

Eine rudimentärere Methode könnte darin bestehen, einen Link zu einer AppSettings.config-Datei für alle AppSettings in Ihrer web.config zu haben (ähnlich wie bei Verbindungen), d. H.

<appSettings configSource="_configs/AppSettings.config" />

Lassen Sie dann einen Ordner mit jedem Ihrer Entwickler eine Version in einem Unterordner haben (dh / _configs / dave /). Wenn ein Entwickler an seinem eigenen Code arbeitet, kopiert er ihn aus dem Unterordner in das Stammverzeichnis des verknüpften Ordners.

Sie müssen sicherstellen, dass Sie Änderungen an diesen Dateien mitteilen (es sei denn, Sie tokenisieren). Wenn Sie die Datei AppSettings.config außerhalb der Quellcodeverwaltung halten und nur die einzelnen Entwicklerordner (alle) einchecken, müssen diese den richtigen kopieren.

Ich bevorzuge die Tokenisierung, kann aber schwieriger in Betrieb zu nehmen sein, wenn dies nur eine schnelle Lösung sein soll.

Ignorieren Sie die Dateien und haben Sie eine Commom_Web.Config und eine Common_App.Config. Verwenden eines Build-Servers mit kontinuierlicher Integration mit Build-Tasks, die diese beiden in normale Namen umbenennen, damit der Build-Server seine Arbeit erledigen kann.

Wir haben das gleiche Problem und was wir tun, ist

• Überprüfen Sie die web.config mit Testserver- / Produktionswerten
• Der Entwickler wechselt zum Windows Explorer und ändert den schreibgeschützten Modus der Datei
• Bearbeiten Sie die Konfiguration entsprechend ihrer Umgebung.
• Das Einchecken in die web.config erfolgt nur, wenn sich die Bereitstellungswerte ändern oder ein Konfigurationseintrag hinzugefügt oder gelöscht wird.
• Dies erfordert eine gute Menge an Kommentaren für jeden Konfigurationseintrag, da er von jedem Entwickler geändert werden muss

Angenommen, Sie verwenden Visual Studio, warum verwenden Sie nicht unterschiedliche Lösungskonfigurationen? Beispiel: Sie können eine Debug-Konfiguration haben, die Web.config.debug verwendet, und eine Release-Konfiguration, die Web.config.release verwendet. Web.config.debug sollte so etwas wie haben

<appSettings file="C:/Standard_Path_To_Configs/Standard_Name_For_Config.config"> 

mit der Datei Standard_Name_For_Config.config, die alle persönlichen Entwicklereinstellungen enthält, während die Version Web.config.release immer die Produktionseinstellungen enthält. Sie können Standardkonfigurationen in einem quellengesteuerten Ordner speichern und von einem neuen Benutzer von dort übernehmen lassen.