Kürzlich haben wir die Webseite der .NET User Group Bern von .NET Core 2.2 auf .NET Core 3.1 migriert. Einen Überblick der Breaking Changes von Version 2.2 zu 3.1 findest du hier. Das Vorgehen beschrieb Johnny in seinem Blog. Wir verwenden den ConfigurationBuilder, dass theoretisch die App.config funktioniert war uns neu.

Im Rahmen einer Erweiterung machten wir eine interessante Entdeckung zum Thema App.config in .NET Core. Wir waren überrascht, da wir jetzt doch schon ein paar Anwendungen in Reviews sahen, die im klassischen .NET Framework das Konfigurationsmodell von .NET Core nachgebaut hatten.

Bei einer Code-Migration vom klassischen .NET Framework auf .NET Core 3.1 machten wir eine interessante Feststellung. Wir verschoben eine Klasse in eine .NET Standard Library. Diese verwendete die Klasse ConfigurationManager aus dem Namensraum System.Configuration, damit Einstellungen aus der App.config – Datei gelesen werden können. Als wir dies mit .NET Core in der ersten Version anschauten, gab es diese Unterstützung nicht. Wir verfolgten die Entwicklung von .NET Standard, das klassische Konfigurationsmodell hatten wir jedoch nicht mehr auf den Radar.

Seit .NET Standard 2.0 ist das klassische Konfigurationsmodell in .NET Core verfügbar.

Um das auszuprobieren, erstellten wir eine .NET Core Konsolenanwendung.

Als nächsten Schritt fügten wir eine App.Config – Datei hinzu, die einen einfachen Aufbau hat.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="BaseUrl" value="https://www.dnug-bern.ch" />
  </appSettings>
</configuration>

In der Main-Methode der Konsolenanwendung lesen wir diese mit dem ConfiguratonManager aus, so wie es beim klassischen .NET Framework üblich ist.

static void Main(string[] args)
{
    var test = ConfigurationManager.AppSettings.Get("BaseUrl");
    Console.WriteLine(test);
}

Wir starteten die Anwendung und siehe da, der Wert aus der App.config wird dargestellt.

Interessante Aspekte

Theoretisch funktioniert das seit .NET Core 2.0. Für uns war es in zweierlei Hinsicht interessant:

1. Wir beschäftigen uns seit der Version 1.0 mit .NET Core, bis .NET Core 2.0 gab es nur den neuen Ansatz mit dem ConfigurationBuilder. Bereits mit der Version 2.0 sind wir davon ausgegangen, dass dieses Konzept nicht mehr in die Nachfolgeversion Einzug halten wird. Der Confirmation Bias hatte uns in diesem Kontext einen Streich gespielt.
2. Mit Blick auf die kommende Version 5.0 wird das ganze interessant für Anwendungsmigrationen. In einem Umfeld, wo die automatische Verteilung der Anwendungen und Konfigurationen bereits seit Jahren (zum Beispiel mit Octopus) gemacht wird, besteht die Möglichkeit klassische .NET Framework – Anwendungen mit weniger Aufwand auf die Version 5 zu portieren. Aus dem Blickwinkel des Qualitätskriterium Sicherheit ist das ein interessanter Aspekt.

Gerade bei alten Anwendungen ohne Testautomatisierung und schlechter Dokumentation kann die Abwärtskompatibilität zum klassischen Framework einen strukturierten Übergang ermöglichen und die Laufzeit der Anwendung verlängern. Zudem besteht die Chance auf weniger kostenintensiven Überraschungen.

War dir dieser Aspekt bewusst? Dein Feedback interessiert mich!