Wie .NET Einstellungen aus app.config unter der Haube liest: Eine Analyse für Wissbegierige

Einleitung: Eine Frage, die jeden .NET-Entwickler quält

Haben Sie sich jemals gefragt, was tatsächlich passiert, wenn Sie ConfigurationManager.AppSettings["myKey"] schreiben? Die meisten Entwickler nehmen es einfach als gegeben hin: Zeile geschrieben – Wert erhalten. Aber wenn Sie etwas tiefer graben (und das tut jeder wissbegierige Geist nach dem Lesen einer populären Frage auf Stack Overflow), werden Sie einen ganzen Mechanismus entdecken, der hinter diesem einfachen Aufruf verborgen liegt.

In diesem Artikel zeigen wir nicht nur, wie man Einstellungen aus app.config oder web.config in C# liest. Wir schauen „unter die Haube": Wir analysieren, wie das .NET Framework XML parst, welche Klassen an diesem Prozess beteiligt sind und warum Ihre Einstellungen manchmal nicht gelesen werden (Spoiler: Nicht nur der Cache ist schuld).

Wenn Sie jemals in die Situation geraten sind, dass ConfigurationManager.AppSettings["ConnectionString"] null zurückgibt, obwohl die Konfigurationsdatei daneben liegt – dieser Artikel ist für Sie.

1. Grundlagen: Struktur der Konfigurationsdatei

Bevor wir uns in die Tiefen stürzen, erinnern wir uns daran, wie eine typische app.config (oder web.config) aussieht. Alles beginnt mit dem Wurzelelement <configuration>:

<?xml version="1.0" encoding="utf-8" ?>\n<configuration>\n  <appSettings>\n    <add key="ApiUrl" value="https://api.example.com"/>\n    <add key="TimeoutSeconds" value="30"/>\n  </appSettings>\n  <connectionStrings>\n    <add name="MainDb" connectionString="Server=.;Database=MyDb;Trusted_Connection=true;"/>\n  </connectionStrings>\n</configuration>

Diese XML-Datei ist nicht nur eine Ansammlung von Zeichenfolgen. Es ist eine streng typisierte Struktur, die .NET auf besondere Weise interpretiert. Und hier beginnt das Interessante.

2. Wie ConfigurationManager funktioniert: Vom Aufruf zum Ergebnis

Wenn Sie ConfigurationManager.AppSettings["ApiUrl"] aufrufen, geschieht folgende Ereigniskette:

\n
1. Bestimmung der Konfigurationsdatei. Das System ermittelt, welche Datei genau gelesen werden soll. Für eine Anwendung ist dies YourApp.exe.config (neben der exe), für eine Webanwendung die web.config im Stammverzeichnis. Wenn die Datei nicht existiert, wird eine leere Sammlung zurückgegeben.
\n
2. Laden des XML. Die Datei wird als XML-Dokument gelesen. Verwendet wird System.Xml.XmlDocument oder der effizientere XmlReader (abhängig von der .NET-Version).
\n
3. Suche des Abschnitts. Es wird nach dem Element <configuration> gesucht, dann darin nach <appSettings>.
\n
4. Parsen der Werte. Jedes untergeordnete Element <add> mit den Attributen key und value wird in ein Schlüssel-Wert-Paar umgewandelt und in einer NameValueCollection abgelegt.
\n
5. Caching. Das Ergebnis wird zwischengespeichert. Ein erneuter Aufruf von ConfigurationManager.AppSettings liest die Datei nicht erneut – er bezieht die Daten aus dem Cache.
\n

Wichtige Nuance: Caching und Änderungen

Wenn Sie die app.config während der Laufzeit der Anwendung ändern, wird ConfigurationManager.AppSettings diese Änderungen nicht sehen, solange die Anwendungsdomäne nicht neu geladen wird. Dies ist eine der häufigsten Ursachen für Fehler: „Ich habe die Einstellungen geändert, aber das Programm verwendet immer noch die alten!".

Um die Konfiguration zwangsweise neu zu lesen, können Sie ConfigurationManager.RefreshSection("appSettings") verwenden, aber das ist eher ein Workaround als eine Lösung.

3. Abschnittshandler: Benutzerdefinierte Abschnitte

Ihnen ist wahrscheinlich aufgefallen, dass es in der web.config nicht nur appSettings gibt, sondern auch system.web, system.net und andere. Jeder dieser Abschnitte wird von einem eigenen Abschnittshandler verarbeitet – einer Klasse, die