Wozu *.config-Dateien?
Vielleicht habe ich ja ein Brett vor dem Kopf. Ich benutze Programmeinstellungen, die zur Laufzeit aus *.settings aus ausgelesen werden (.NET 2.0). Das klappt natürlich.
Beim Compilieren werden im Build-Verzeichnis neben den exe- und dll-Dateien noch *.config-Dateien erzeugt. Aber warum? Was kann ich damit anfangen? Wenn ich dort Einstellungen per Texteditor ändere, dann interessiert das mein compiliertes Programm nicht die Bohne.
Im konkreten Fall habe ich auf einem entfernten Rechner einen Applikationsserver als Dienst laufen. Dieser wiederum schickt SQL-Anfragen an einen Datenbankrechner. Da es mehrere davon gibt (Testmaschine, Produktivmaschine) wird der ConnectionString, den der Applikationsserver beim Starten aufbaut, mit der jeweiligen DB-Rechner-IP ergänzt. Tatsache ist nun, dass erst durch ein Ändern in den Settings (IP-Adresse) und Neucompilieren des Applikatinsservers dieser auf eine andere IP geht. Ein manuelles Editieren der Config-Datei bringt nichts.
Ich habe hier etliche .NET-Bücher liegen, die auf diesen (m. E. nicht unwichtigen) Aspekt nicht eingehen. Auch das "Neue Konfigurationsmodell von .NET 2.0", mit dem der Anwender seine eigenen Einstellungen ändern und speichern kann, nützt mir dabei ja nichts, obwohl es immer wieder in der Literatur und im Forum durchgekaut wird.
Wozu dienen also die *.config-Dateien im Build-Verzeichnis, wenn (ich zumindest) damit das Laufzeitverhalten von Programmen und DLL's nicht beeinflussen kann?
Gruß,
retnug
Hallo
Einfach mal eine prinzipielle Antwort auf die Frage (Titel).
Es ist durchaus die Meinung, dass eine config Datei zur Konfiguration der Anwendung da ist. Eine Änderung dieser Datei bewirkt dann eine veränderte Konfiguraion.
Nun bleibt natürlich anzumerken, dass es darauf ankommt, wie die Du Konfiguration in Deinem Programmcode verwendest. Gerade die ConnectionStrings sind ja solche Kandidaten und bei uns hier funktioniert das einwandfrei, das darfst Du glauben =)
kaepten
PS: Huch zu langsam, löschen kann man nicht, also ist der Post halt da. Der Link oben vom Vorschreiber sagt eigentlich alles...
Hm, dass als Hinweis ziemlich schnell
> gepostet wird, hatte ich mir fast schon gedacht. 😉 Aber wo steht denn dort etwas zu meiner Frage? Ich will ja nicht erst eine Einstellung ändern, wenn das Programm bereits läuft sondern schon vorher. Deswegen brauche ich auch keine userspezifische config-Datei.
Hallo retnug,
Wozu dienen also die *.config-Dateien im Build-Verzeichnis, ...?
keine Ahnung. Eigentlich werden die .config-Dateien aus einem Unterverzeichnis von C:\Dokumente und Einstellungen<user>..." geladen. Dort solltest du mal suchen und diese Datei ändern.
herbivore
Eigentlich werden die .config-Dateien aus einem Unterverzeichnis von C:\Dokumente und Einstellungen<user>..." geladen. Dort solltest du mal suchen und diese Datei ändern.
Und das ist genau das, was ich nicht brauche. Ich bräuchte einen Mechanismus, bei dem die Anwendung selbständig einen bestimmten Einstellungswert holt anstatt auf die Einstellung aus der app.config zur Kompilierungszeit zuzugreifen. Drücke ich mich denn so undeutlich aus? 😁 Falls das doch mit manuellen Änderungen in den *.exe.config-Dateien im Build-Verzeichnis möglich ist, dann gebe man mir bitte einen Tipp, wie das auch bei mir möglich sein kann.
und bei uns hier funktioniert das einwandfrei, das darfst Du glauben Und mit welchem Mechanismus? User-Settings? Brauch' ich nicht. Erwähnte ich es bereits? 😉
OK. Es scheint also nicht zu gehen, da nicht so unter .NET vorgesehen. Muss ich mir dann wohl etwas eigenes stricken.
Hallo retnug,
so wie ich es verstanden habe, willst du eine config-Datei per Editor ändern und die Änderung soll von den Anwendung ohne Neucompilieren angezogen werden. Richtig? Wenn ja, dann siehe meine schon gegebene Antwort. Die ist dann schon auf deine Frage zugeschnitten.
Oder soll die Änderung auch ohne Neustart der Anwendung angezogen werden? Wenn ja, dann hast du dich wirklich undeutlich ausgedrückt, weil du was von Neucompilieren geschrieben hast.
herbivore
so wie ich es verstanden habe, willst du eine config-Datei per Editor ändern und die Änderung soll von den Anwendung ohne Neucompilieren angezogen werden. Richtig? Wenn ja, dann siehe meine schon gegebene Antwort. Die ist dann schon auf deine Frage zugeschnitten.
Auf diese Art wäre es möglich. Allerdings greift die Anwendung beim Starten dann ja auf User-Einstellungen zurück (die vorher explizit zur Laufzeit geändert werden müssten damit sie via "Properties.Settings.Default.Save()" überhaupt gespeichert werden). Was nützt mir aber das, wenn eine bestimmte Einstellung NICHT-userspezifisch beim Programmstart gezogen werden soll UND zur Kompilierungszeit evtl. einen abweichenden Wert hat?
Wieder konkret: Auf den Rechner, auf dem der .NET-Applikationsserverdienst läuft, loggen sich die Entwickler bzw. Admins per Remote ein. Wenn ich selbst beispielsweise auf dem Rechner bin, würde meine ganz persönliche User-Einstellung beim Programmstart herangezogen werden. Das ist aber unerwünscht weil dieser Dienst nunmal mit einer Konfiguration laufen mus, die für alle User gelten. Und nicht nur für den, der den Dienst gestartet hat.
Oder soll die Änderung auch ohne Neustart der Anwendung angezogen werden? Wenn ja, dann hast du dich wirklich undeutlich ausgedrückt, weil du was von Neucompilieren geschrieben hast.
Nein, es geht nur um den Neustart. Das mit dem "Neucompilieren" bezog sich auf das grundsätzliche Verhalten, dass eben Änderungen in der *.exe.config nach dem Kompilieren sich nicht auf die Einstellungen auswirken, die die Anwendung zur Laufzeit heranzieht.
Hallo retnug,
ok, dann war das noch noch etwas anders, als ich gedacht habe. Vergiss "C:\Dokumente und Einstellungen<user>...".
Im [Tutorial] Das neue Konfigurationsmodell im .NET Framework 2.0 gibt benutzerbezogene und anwendungsbezogene Settings. Wenn du (mit dem Editor) die .config-Datei änderst, die die anwendungsbezogenen Settings enthält, dann sollte ein Neustart der Anwendung ausreichen, um die neuen Settings anzuziehen.
Wenn das nicht der Fall ist, änderst du die falsche .config-Datei bzw. die richtige .config-Datei am falschen Ort.
herbivore
Als Ergänzung möchte ich noch hinweisen auf Read/Write App.Config File with .NET 2.0. Das sagt, wie Einstellungen in der app.config zur Laufzeit geändert werden können.
Jürgen
Ich habe nun folgendes herausgefunden:1.Wenn ich in der *.exe.config bei den <applicationSettings einen Wert verändere, dann wirkt sich das beim Programmstart tatsächlich aus. Sehr schön. Aber: 1.Bei meinem Windows-Service tut es dies nicht. Nun ist es so, dass bei einem Windows-Service das Arbeitsverzeichnis grundsätzlich "c:\Windows\system32" ist. 1.Also dachte ich mir: kopier die ganzen Files doch dahin, installier den Dienst neu und probier es aus. Aber auch dann nimmt die Anwendung (=Windows-Service) nicht die Einstellungen aus der *.exe.config.
Sehr schade.
@juetho: Page not found. Im übrigen möchte ich ja ungern die app.config zur Laufzeit ändern.
Hallo retnug,
@juetho: Page not found.
ich habe den Link korrigiert. Die richtige Seite war ja anhand ihres Titels leicht zu finden.
herbivore
Ach Kinners! Jetzt weiss ich, was falsch läuft.
In meinem Framework werden für alle Projekte alle Einstellungen via separater app.config bzw. VS2005-Designer abgelegt und die Defaultwerte definiert. Der Zugriff darauf zur Laufzeit geschieht aber nicht generisch, sondern (gewollt!) via Durchlaufen einer System.Configuration.SettingsPropertyCollection, die von dem jeweiligen Projekt, dass die Anfrage nach einem Settingswert stellt, an eine zentrale statische Klasse "tief unten" in meinem Core-Projekt weitergeleitet und dort behandelt wird. Damit habe ich auch die Möglichkeit, Einstellungswerte an zentraler Stelle mit Datenbankinhalten für Benutzereinstellungen zu behandeln.
Bisher lautete der Code zum Auslesen eines Wertes:
static string GetDefaultvalueString(string key, Assembly assembly, bool logIfNotFound, SettingsPropertyCollection properties)
{
string ret = ESText.EmptyString;
bool found = false;
//Schleife ueber alle Properties
foreach (SettingsProperty sp in properties) {
//Key-Namen vergleichen
if (ESText.IsEqual(key, sp.Name)) {
//Key gefunden
found = true;
//Defaultwert auslesen
ret = (string)sp.DefaultValue;
//Schleife beenden
break;
}
}
if (!found) {
//Defaultwert nicht vorhanden -> Logging
(...)
}
return ret;
}
Das Problem hierbei ist, dass das SettingsProperty-Objekt sp via "sp.DefaultValue" den Wert aus der app.config liefert und nicht den, der in der *.exe.config nach dem Kompilieren geändert worden ist.
Ich habe es nun so abgeändert, dass in der Schleife nur noch geprüft wird, ob der Key vorhanden ist. Falls ja wird der gewünschte Wert mit "properties[key].DefaultValue" dann gelesen:
static string GetDefaultvalueString(string key, Assembly assembly, bool logIfNotFound, SettingsPropertyCollection properties)
{
string ret = ESText.EmptyString;
bool found = false;
//Schleife ueber alle Properties
foreach (SettingsProperty sp in properties) {
//Key-Namen vergleichen
if (ESText.IsEqual(key, sp.Name)) {
//Key gefunden
found = true;
//Defaultwert auslesen
try {
ret = (string)properties[key].DefaultValue;
}
catch {
//Fehler beim Auslesen
(...)
}
//Schleife beenden
break;
}
}
if (!found) {
(...)
}
return ret;
}
Ich verzichte übrigens auf ein in's Blaue geratenes "ret = (string)properties[key].DefaultValue;" ohne vorher mit der foreach-Schleife zu testen, ob der Key überhaupt vorhanden ist. Das wäre zwar nicht unelegant, dauert aber bei nicht vorhandenen Keys durch die Exception viel länger.
Ich habe gerade eine "entsetzliche" Feststellung machen müssen: Wenn ich User-Einstellungen in der *.config-Datei einer eingebundenen DLL ändere, dann wirkt sich das zur Laufzeit im Code innerhalb einer Methode der DLL nicht aus. Und dies jetzt wirklich ohne jedes Framework-Gedöns meinerseits. Ich habe es in einer Mini-Testanwendung mit einer eingebunden (Verweis) Mini-DLL ausprobiert.
Ich habe in der DLL ClassLibrary1.dll eine "Einstellungsdatei" CommonSettings.settings mit einem Schlüsselwertpaar key/valueX. Nach dem Kompilieren ändere ich nun in der ClassLibrary1.dll.config den value von "keyX" nach "keyY" Wenn ich nun in meiner Minimal-EXE eine in der DLL definierte Klasse instanziiere und im Konstruktor der Klasse (und damit ja zur Laufzeit in der DLL) bin, dann bringen mir weder Properties.CommonSettings.Default.PropertyValues, noch Properties.CommonSettings.Default.Properties den geänderten Wert. In meiner EXE klappt das mit dem Ändern von Werten in der *.config-Datei anstandslos.
Ist dieses Verhalten so gewollt? Das würde ja bedeuten, dass sämtliche Einstellungen in *.config-Dateien wirkungslos bleiben, sobald die zugehörige DLL bzw. Assembly nicht ausgeführt, sondern lediglich als Verweis eingebunden ist.
Bin ich der einzige, bei dem das so ist oder braucht sonst niemand eine Konfiguration von DLL's in seinen Anwendungen?
Für einzelne DLLs kann man keine eigenständigen .config Dateien verwenden.
Hatte vor ein paar Wochen das gleiche Problem.
Es gibt nur eine App.config für die gesamte Anwendung aber es ist nicht möglich für einzelne DLLs seperate App.configs zu verwenden.
Falls du wirklich eigene Konfigurationsdateien benötigst, würde ich mit XML Serialisierung arbeiten.
Mir persönlich ist dieser ganzer .config Schnickschnack eh zu unflexibel. Ich speicher meine Einstellungen (applikations-, rechner- under benutzerbezogene Paramater) einfach an einer zentralen Stelle in einer SQL Datenbank. Dazu habe ich mir einige Proxyklassen geschrieben, dir mir bequem den Zugriff auf meine Parameter bietet. Gefällt mir persönlich wesentlich besser als alles mit XML und .config machen zu müssen.
Ist aber nur meine Lösung.
Hallo,
ich bin gerade sehr verwirrt, was die Konfigurationsgeschichte angeht. Bei der Suche bin ich hier rüber gestolpert, und hoffe, mein Thema passt dazu.
@Herbivore
Du hast geschrieben, dass die .config-Dateien aus dem c:\Dokumente und Einstellungen...-Verzeichnis geladen werden. Also NICHT direkt vom selben Verzeichnis. Bei mir kann ich keine Datei finden in dem Verzeichnis finden, die mein Programm da anfasst.
Ich habe ein kleines Programm, das über eine app.config Einstellungen lädt, und auch dort wieder reinspeichert. Solange die .config-Datei nach dem Kompilieren da war, habe ich gedacht: Naja, da drin werden diese Einstellungen zur Laufzeit dann gespeichert, und wieder geladen.
Jetzt habe ich die .exe aber an eine andere Stelle verschoben, ohne die .config-Datei mitzunehmen, ja, ich habe sie sogar an der alten Stelle gelöscht, und trotzdem kann ich problemlos Einstellungen laden und speichern...
Wo zum Geier ist denn dann die Datei, in der die Einstellungen abgelegt werden. Habe mein ganzes Laufwerk nach .config-Dateien abgesucht, aber da ist keine dabei, die das richtige Änderungsdatum hat. Ich verstehe grad gar nix mehr! Wozu braucht man denn die .config wenns dann doch anders geladen wird?
Kennt sich damit jemand aus?
Ok, sorry,
hat sich grade erledigt. Die Windows-Suche ist wohl nicht so erfolgreich wie man meinen könnte. Habe mal direkt in das Verzeichnis (Lokale Einstellungen\AppName...) geschaut, und da liegt dann diese user.config (mit richtigem Datum).
Komisch, dass die bei der Suche nicht gefunden wurde!
Also, hat sich erledigt!