In vb.net gibt es da die "Settings" welche du mit My.Settings aufrufen kannst.

Im Forum & im Web wirst du schnell fündig wenn du danach suchst

EDIT: MSDN - My.Setting

Du findest diese unter den "Projekteinstellungen" --> "Settings"
Dort können StringCollections , Strings , Integer usw. angelegt werden.

Diese werden dann unter C:\Users\MaxMustermann\AppData gespeichert.

Ich bin ein Freund von .ini-Dateien wenn es um lokale Sachen geht, welche nur für diesen einen PC gelten.
Bei Einstellungen welche mehrere Rechner im Netzwerk benötigen verwende ich Datenbanken. (Der Connection-String zur DB steht zB wieder in der .ini.)

lg

dive26 schrieb:

2) INI-Dateien (txt oder xml Dateien im Programmverzeichnis)
3) Datenbank im Programmverzeichnis

Das mit dem "im Programmverzeichnis" führt sehr oft zu ungewollten Verhalten:
Wenn Software installiert wird, landet diese im Programm-Verzeichnis (z. B. C:\Program Files). Dort haben nur Administratoren Schreibrechte. Das bedeutet, dass die Einstellungen nur gespeichert werden können, wenn das Programm mit einem Adminsitratorbenutzer gestartet wurde (oder es wurden manuell entsprechende Rechte auf den ordner gesetzt).
Falls dieses Verhalten nicht explizit erwünscht ist (bei deinem Zweck "Datensicherung" würde ich aber sogar fast schon davon ausgehen), rate ich stark davon ab.

Sind die Einstellungen Per-Machine oder Per-User? Bei letzterem bieten sich die Anwendungsdaten (%appdata%/%localappdata%) an.
My.Settings verwendet eben diese Verzeichnisse. Man kann auch davon ausgehen, dass das (in den meisten Fällen) angebracht ist, denn sonst hätte MS sich nicht dazu entschieden, es so zu machen.

INI-Dateien wird heutzutage nur noch selten verwendet. Meistens verwendet man heute eine einfache Serialisierung von Klassen nach XML, JSON oder ein anderes Format (My.Settings verwendet XML). Wenn INI, dann würde ich sogar soweit gehen, einen eigenen Sserializer zu verwenden, statt die WinAPI-Funktionen.

Ob die Registry heute noch oft verwendet wird, kann man (IMO) nicht sagen. Windows selbst macht es, .NET-Programme allerdings nicht häufig, da es einfachere Alternativen (My.Settings) gibt, die auch von Haus aus schon eine gute Abstraktion bieten.

Kein Problem. Eine Standard-XML-Datei, nur der Pfad dieser Datei ist kryptisch.

Du kannst diese inerhalb deines Projektes aufrufen wann immer du willst.

Wenn du eine STringCollection anlegst würde das wiefolgt gehen:

So unterschiedlich sind die Ansichten. Ich vermeide seit einiger Zeit die Verwendung von INI-Dateien wo es mir möglich ist und verwende zum Speichern von Einstellungen grundsätzlich die Registry.

Wenn es sich um eine Anwendung handelt, die mit mehreren Clients in einem Netzwerk die Konfiguration teilt, handelt es sich in den meisten Fällen eh um einen Anwendungsfall, bei dem auch eine Datenbank zum Einsatz kommt, so dass diese gemeinsamen Daten eben genau hier abgelegt werden.

Geht es darum, zusätzlich benutzer- oder rechnerspezifische Dateien abzulegen, kann hier auch eine ggf. vorliegende Datenbank herhalten oder im gebräuchlichsten Fall werden dazu dann die übers Framework auslesbaren Anwendungsverzeichnisse für den aktuellen Benutzer und für alle Benutzer verwendet. Je nach Art der Dateien und Typ der Anwendung kann man die Wahl des Speicherorts aber natürlich auch dem Benutzer freistellen. Die Wahl wird dann wiederum in der Registry bzw. Datenbank vermerkt.

My.Settings ist IIRC nur in VB.NET verfügbar, und da ich auch viel in C# mache könnte ich damit nicht viel anfangen, weshalb ich das eigentlich nie nutze.

dive26 schrieb:

Ok, dann werde ich My.Settings verwenden

Das geht wesentlich einfacher.
Du kannst beim Anlegen der Settings jedem einen Initialwert geben.
Beim Start werden die Initialwerte geladen und mit denen aus dem gespeicherten File überschrieben.
Kommen also neue Settings hinzu, erhalten diese den Initialwert, alle anderen werden ausgelesen.
Wenn die Projekteinstellung stimmt, werden diese automatisch beim Beenden des Programms gespeichert, es besteht also kein weiterer Handlungsbedarf.
Wenn Du allerdings Dein Programm von einem anderen Pfad aus startestr (Debug, Release, der installierte Pfad), wird initial je eine neue Settingsdatei angelegt, d.h., Du hast ggf. bei Debug und Release verschiedene Settings.

Die XML-Datei zu finden ist möglich, nicht sonderlich einfach. Die Dateiendung ist nicht .xml, sondern .config.
Für die Benutzerkonfiguration heißt sie user.config und liegt irgendwo in %appdata% oder %localappdata%.



Ich glaube für Computerspezifische Einstellungen heißt sie machine.config. Da bin ich mir aber nicht ganz sicher.

Welche Einstellung von welchem Typ sein soll kann man einstellen.

Arby schrieb:

My.Settings ist IIRC nur in VB.NET verfügbar, und da ich auch viel in C# mache könnte ich damit nicht viel anfangen

My.Settings gibt es in C# auch und heißt dort einfach nur anders, nämlich Properties.Settings.Default.

nikeee13 schrieb:

My.Settings gibt es in C# auch und heißt dort einfach nur anders, nämlich Properties.Settings.Default.

Okay, gut zu wissen, aber ich werde dennoch weiterhin die Variante mit der Registry bevorzugen.

Hier steht, wie es geht:
codeproject.com/Articles/12789…ettings-in-machine-config
msdn.microsoft.com/en-us/library/a65txexh.aspx

@dive26:: Soll jeder (separat eingeloggte) User seine eigenen Settings haben
oder
sollen immer alle User dieselben Settings haben?

Dann solltest Du auch nur genau eine Konfigurationsdatei verwenden, da musst Du den Inhalt aber selbst verwalten.

Übersicht: Strategien zum persistieren von Einstellungen
Ini-Dateien schneiden da am schlechtesten ab, denn bereits der Xml-Standard ist wesentlich mächtiger (ganz zu schweigen vom typDataset).
Und hier habichmal ein ganz eigenes Format vorgestellt: kompakt, typisiert und kann sowohl Einzelwerte als auch Tabellen: flexible Settings