| 

.NET C# Java Javascript Exception

5
Ich möchte Konfigurationsdaten nicht in der Systemregistrierung, sondern in programmspezifischen Initialisierungsdateien ablegen. Wie gehe ich dazu vor?
News:
23.03.2011
Justin 51 1 3
9 Antworten
4
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:

MessageBox.Show (Properties.Settings.Default.MeineEigenschaft);


Hier findest Du noch mehr Infos zu den Application-Settings:
Application Settings Overview
23.03.2011
mblaess 1,2k 1 9
mblaess 1,2k 1 9
1
Eine passende Klasse dafür gibt es zum Beispiel hier: http://www.codeproject.com/KB/files/VbNetClassIniFile.aspx
23.03.2011
m.fuchs 1,8k 2 8
1
Oder evtl. ist auf dotnet-snippets.de was passendes für Dich dabei.
23.03.2011
Jorgen Schumann 1,6k 2 9
0
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.
25.03.2011
pinchbeck 373 1 8
0
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.
25.03.2011
pinchbeck 373 1 8
es war nich mein Absicht die Antwort doppelt zu posten... ist irgendwie passiert :\
pinchbeck 25.03.2011
0
@pinchbeck:

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.
26.03.2011
mblaess 1,2k 1 9
mblaess 1,2k 1 9
0
@mblaess

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
26.03.2011
pinchbeck 373 1 8
0
Hallo pinchbeck,

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.

LG, Micha
26.03.2011
mblaess 1,2k 1 9
0
Oder, was ich im Überfliegen noch nicht gesehen habe, einfach eine eigene Klasse machen und diese in eine Datei Serialisieren.

1) Sehr einfach.
2) Sehr zuverlässig.
3) Man kann es speichern wo man will. Vorzugsweise aber NICHT unter c:\ oder im Installationsverzeichnis.
26.03.2011
GENiALi 2,5k 1 2 8

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH