Ich möchte Konfigurationsdaten nicht in der Systemregistrierung, sondern in programmspezifischen Initialisierungsdateien ablegen. Wie gehe ich dazu vor?
Von klassischen INI-Dateien würde ich Dir eher abraten. Die meisten Snippets oder Hilfsklassen sind eh nur Wrapper für die API-Funktionen "GetPrivateProfileString" bzw. "WritePrivateProfileString".
Warum verwendest Du nicht einfach die Application-Settings-Datei in Visual-Studio? Das ist eine XML-Konfigurationsdatei, die so ziemlich jeden Datentypen serialisieren kann. Die Settings können Benutzer- oder Applikationsspezifisch sein und an Steuerelemente gebunden werden.
Der Zugriff ist kinderleicht.
In VB.NET direkt über die My.Settings-Klasse. In C# musst Du den Umweg über die Properties gehen, z.B. so:
ich rate dringend von Application-Settings ab. mit solchen Einstellungen habe ich nur schlechte Erfahrungen gemacht, wie Probleme beim Updaten, verschwindende Settings, versteckte Config-Dateien. momentan entwerfe ich für jedes Programm meine eigene XML-Struktur und schreibe selbst statische Klassen (und Unterklasse) die mithilfe von LINQ und XPath die Settings auslesen oder speichern. ein sehr großer Vorteil davon ist, dass man die Settings schön grupieren kann.
ich rate dringend von Application-Settings ab. mit solchen Einstellungen habe ich nur schlechte Erfahrungen gemacht, wie Probleme beim Updaten, verschwindende Settings, versteckte Config-Dateien. momentan entwerfe ich für jedes Programm meine eigene XML-Struktur und schreibe selbst statische Klassen (und Unterklasse) die mithilfe von LINQ und XPath die Settings auslesen oder speichern. ein sehr großer Vorteil davon ist, dass man die Settings schön grupieren kann.
Wir verwenden seit Jahren nur noch die Application-Settings und sind sehr zufrieden damit.
Ich kann Deine Probleme nicht nachvollziehen.
Die .config-Dateien sind nicht versteckt: Du findest Sie im BIN-Verzeichnis Deiner Anwendung, bzw. bei benutzerdefinierten Einstellungen im jeweiligen Benutzerverzeichnis (z.B. C:\Users\Benutzername\AppData\Local\NameDeinerAnwendung\xy.config).
Und Probleme beim Updaten sind imho davon abhängig, welches Setup-Tool Du verwendest und wie das Setup gestrickt ist.
Die Application-Settings sind nunmal die von Microsoft empfohlene Lösung - und hierzu gibt es auch massig Literatur.
Deine Lösung mag für Dich die beste Wahl sein, allerdings gibt es mind. 3 Punkte, die Du erwägen solltest:
1. Bekommst Du Deine Anwendung nicht von Microsoft zertifiziert, weil Sie nicht den strengen Microsoft-Standards entspricht.
2. Andere Programmierer, müssten sich in Dein Config-Framework einarbeiten - was Zeit und Aufwand kostet.
3. Einige UI-Controls von Drittanbietern (z.B. Infragistics.UltraWinDock) und die Enterprise Library benötigen die Application-Settings, um Ihre Einstellungen zu speichern.
wenn du die Application-Settings so toll findest, würde ich dann gerne sehen wie du über 500 verschiedene Programmeinstellungen damit verwaltest (Verzeichnisse, Farben, Schriftarten, Fensterpositionen, etc.), eine flache Struktur... macht bestimmt Spaß :P
zu 1: ich kann noch verstehen, dass M$ bestimmte Dinge in der App.config etc. haben will aber, dass sie mir meine eigene Konfig-Dateien verbieten... da ist ein Beweis nötig
zu 2: als wären die Application-Configs total einfach. wie verhinderst du zB unsinnige Einstellungen in solchen Konfigs die vom Benutzer vorgenommen werden können wie zu große/kleine Zahlen etc. wenn er auf die Idee kommt die Konfigs zu editieren. ich kann in solchen Fällen jederzeit auf Default-Werte zurückschalten weil mein Framework die Eigaben überprüft, Application-Settings bieten meines Wissens nach so was nicht.
zu 3: klar, einzelne Connection-Strings oder andere Sachen, die sich nur schwer woanders speichern lassen muss ich in den standard Config-Dateien ablagern
Ich kann Deinen Frust verstehen. Aber die von Dir genannten Probleme treten bei uns nicht auf.
Ich würde das hier auch nicht posten, wenn ich nicht von den Application-Settings überzeugt wäre.
Unsere Anwendungen haben locker über 130 Grundeinstellungen mit allen möglichen Datentypen (u.a. String-Collections & Binaries) - und ja, es macht Spaß :-)
Bestimmte Einstellungen, die Du genannt hast, wie z.B. Farben, Fensterpositionen etc. speichern wir aber in einer zentralen SQL-Server-Datenbank, damit Sie dem Benutzer auf jedem Rechner zur Verfügung stehen.
Unsinnige Einstellungen vermeiden wir, indem wir die Benutzer (und meistens auch die Admins) nicht an die Config-Dateien lassen :-) Da genügt schon ein fehlendes XML-Endtag und die Config ist nicht mehr zu gebrauchen.
Für die Client- und Serverkonfiguration gibt daher es bei unseren Anwendungen diverse Assistenten und Konfigurationsmasken, die die Benutzer bei der individuellen Einrichtung unterstützen.
Die Validierung der Einstellungen realisieren wir über die Validation Blocks der Enterprise Library.
