Wann - und warum - sollten Sie Daten in der Windows-Registrierung speichern?

Als Entwickler sind Tools, die Konfiguration / Optionen in der Registrierung speichern, der Fluch meines Lebens. Ich kann Änderungen an diesen Optionen nicht einfach nachverfolgen, sie nicht einfach von Maschine zu Maschine portieren, und all das lässt mich wirklich nach den guten alten Zeiten von INI-Dateien sehnen ...

Was sollte ich beim Schreiben meiner eigenen Anwendungen - wenn überhaupt - in die Registrierung einfügen und nicht in altmodische Konfigurationsdateien, und warum?

• Die ursprüngliche (WIN3) Konfiguration wurde in der Datei WIN.INI im Windows-Verzeichnis gespeichert.
• Problem: WIN.INI wurde zu groß.
• Lösung (Win31): Einzelne INI-Dateien im selben Verzeichnis wie das Programm.
• Problem: Dieses Programm kann in einem Netzwerk installiert und von vielen Personen gemeinsam genutzt werden.
• Lösung (Win311): Einzelne INI-Dateien im Fensterverzeichnis des Benutzers.
• Problem: Viele Benutzer teilen möglicherweise einen Windows-Ordner, der ohnehin schreibgeschützt sein sollte.
• Lösung (Win95): Registrierung mit separaten Abschnitten für jeden Benutzer.
• Problem: Die Registrierung wurde zu groß.
• Lösung (WinXP): Große Blöcke einzelner Daten werden in den eigenen Anwendungsdatenordner des Benutzers verschoben.
• Problem: Gut für große Datenmengen, aber komplex für kleine Datenmengen.
• Lösung (.NET): Kleine Mengen fester, schreibgeschützter Daten, die in .config (Xml) -Dateien im selben Ordner wie die Anwendung gespeichert sind, mit API zum Lesen. (Lese- / Schreib- oder benutzerspezifische Daten bleiben in der Registrierung)

Wenn ich dies sowohl aus Benutzer- als auch aus Programmiererperspektive betrachte, muss ich sagen, dass es wirklich keine gute Ausnahme gibt, etwas in die Registrierung aufzunehmen, es sei denn, es handelt sich um Dateizuordnungen oder maschinenspezifische Einstellungen.

Ich komme aus der Denkschule, die besagt, dass ein Programm von jedem Ort aus ausgeführt werden kann, an dem es installiert ist, dass die Installation vollständig innerhalb einer Maschine oder sogar auf eine andere Maschine verschoben werden kann und die Ausführung nicht beeinträchtigt.

Alle konfigurierbaren Optionen oder erforderlichen DLLs usw., wenn sie nicht gemeinsam genutzt werden, sollten sich in einem Unterverzeichnis des Installationsverzeichnisses befinden, damit die gesamte Installation problemlos verschoben werden kann.

Ich verwende viele kleinere Dienstprogramme wie Programme. Wenn es also nicht auf einem USB-Stick installiert und an einen anderen Computer angeschlossen und einfach ausgeführt werden kann, ist es nichts für mich.

Microsoft-Richtlinie:

• Vor Windows 95 haben wir INI-Dateien für Anwendungsdaten verwendet.
• In der Windows 95 - XP - Ära haben wir die Registrierung verwendet.
• Unter Windows Vista verwenden wir INI-Dateien, obwohl sie jetzt auf XML basieren.

Die Registrierung ist maschinenabhängig. Ich habe es nie gemocht, weil es zu langsam wird und es fast unmöglich ist, das zu finden, was Sie brauchen. Deshalb mag ich einfache INI- oder andere Einstellungsdateien. Sie wissen, wo sie sich befinden (Anwendungsordner oder Benutzerordner), sodass sie leicht zu transportieren und für Menschen lesbar sind.

Wann - Sie sind aufgrund der Legacy-Integration oder weil der Systemadministrator Ihres Kunden sagt, dass es so sein soll oder weil Sie in einer älteren Sprache entwickeln, die die Verwendung von XML erschwert, dazu gezwungen.

Warum - In erster Linie, weil die Registrierung nicht so portabel ist wie das Kopieren einer Konfigurationsdatei, die sich neben der Anwendung befindet (und fast gleich heißt).

Wenn Sie .Net2 + verwenden, verfügen Sie über App.Config- und User.Config-Dateien und müssen keine DLLs in der Registrierung registrieren. Halten Sie sich daher davon fern.

Konfigurationsdateien haben ihre eigenen Probleme (siehe unten), diese können jedoch codiert werden und Sie können Ihre Architektur ändern.

• Problem: Anwendungen benötigten konfigurierbare Einstellungen.
• Lösung: Speichern Sie die Einstellungen in einer Datei (WIN.INI) im Windows-Ordner. Verwenden Sie Abschnittsüberschriften, um Daten zu gruppieren (Win3.0).
• Problem: Die WIN.INI-Datei wurde zu groß (und wurde unordentlich).
• Lösung: Speichern Sie die Einstellungen in INI-Dateien im selben Ordner wie die Anwendung (Win3.1).
• Problem: Benötigen Sie benutzerspezifische Einstellungen.
• Lösung: Speichern Sie Benutzereinstellungen in benutzerspezifischen INI-Dateien im Fensterverzeichnis des Benutzers (Win3.11) oder in benutzerspezifischen Abschnitten in der INI-Anwendungsdatei.
• Problem: Sicherheit - Einige Anwendungseinstellungen müssen schreibgeschützt sein.
• Lösung: Registrierung mit Sicherheit sowie benutzerspezifischen und maschinenweiten Abschnitten (Win95).
• Problem: Die Registrierung wurde zu groß.
• Lösung: Die benutzerspezifische Registrierung wurde nach user.dat im benutzereigenen Ordner "Anwendungsdaten" verschoben und nur beim Anmelden (WinNT) geladen.
• Problem: In großen Unternehmensumgebungen melden Sie sich an mehreren Computern an und müssen JEDEN einrichten.
• Lösung: Unterscheiden Sie zwischen lokalen (lokale Einstellungen) und Roaming-Profilen (Anwendungsdaten) (WinXP).
• Problem: xcopy kann Anwendungen wie den Rest von .Net nicht bereitstellen oder verschieben.
• Lösung: APP.CONFIG XML-Datei im selben Ordner wie die Anwendung - leicht zu lesen, leicht zu manipulieren, leicht zu verschieben, kann bei Änderungen nachverfolgt werden (.Net1).
• Problem: Benutzerspezifische Daten müssen immer noch auf ähnliche Weise gespeichert werden (z. B. xcopy deploy).
• Lösung: USER.CONFIG XML-Datei im lokalen oder Roaming-Ordner des Benutzers und stark typisiert (.Net2).
• Problem: Bei CONFIG-Dateien wird zwischen Groß- und Kleinschreibung unterschieden (für Menschen nicht intuitiv), es sind sehr spezifische "Tags" zum Öffnen / Schließen erforderlich, Verbindungszeichenfolgen können zur Laufzeit nicht festgelegt werden, Setup-Projekte können keine Einstellungen schreiben (so einfach wie die Registrierung) und können nicht einfach ermittelt werden Die Datei user.config und die Benutzereinstellungen werden bei jeder neuen installierten Revision gelöscht.
• Lösung: Verwenden Sie das ITEM-Mitglied, um zur Laufzeit Verbindungszeichenfolgen festzulegen, schreiben Sie Code in eine Installer-Klasse, um die App.Config während der Installation zu ändern, und verwenden Sie die Anwendungseinstellungen als Standardeinstellungen, wenn keine Benutzereinstellung gefunden wird.

Wird die Welt untergehen, wenn Sie einige Fensterpositionen und eine Liste der zuletzt verwendeten Elemente in der Windows-Registrierung speichern? Bisher hat es für mich gut funktioniert.

HKEY-CURRENT-USER ist ein großartiger Ort, um triviale Benutzerdaten in kleinen Mengen zu speichern. Dafür ist es da. Es scheint albern, es nicht für den beabsichtigten Zweck zu verwenden, nur weil andere es missbraucht haben.

Einstellungen, die im Roaming-Profil eines Benutzers verfügbar sein sollen, sollten wahrscheinlich in der Registrierung gespeichert werden, es sei denn, Sie möchten tatsächlich manuell nach dem Anwendungsdatenordner des Benutzers suchen. :-)

Lese- und Schreibvorgänge in der Registrierung sind threadsicher, Dateien jedoch nicht. Es hängt also davon ab, ob Ihr Programm Single-Threaded ist oder nicht.

Wenn Sie eine neue App entwickeln und sich für Portabilität interessieren, sollten Sie dies tun NIEMALS Wert auf Daten in der Windows-Registrierung speichern, da andere Betriebssysteme keine (Windows-) Registrierung haben (Hinweis: Dies kann offensichtlich sein, wird jedoch häufig übersehen).

Wenn Sie nur für Win-Plattformen entwickeln ... versuchen Sie, dies so weit wie möglich zu vermeiden. Konfigurationsdateien (möglicherweise verschlüsselt) sind eine viel bessere Lösung. Das Speichern von Daten in der Registrierung bringt keinen Vorteil - (isolierter Speicher ist eine viel bessere Lösung, wenn Sie beispielsweise .NET verwenden).

Etwas abseits des Themas, aber da ich Leute sehe, die sich Sorgen um die Portabilität machen, ist der beste Ansatz, den ich je verwendet habe, die QSettings-Klasse von Qt. Es abstrahiert die Speicherung der Einstellungen (Registrierung unter Windows, XML-Voreinstellungsdatei unter Mac OS und Ini-Dateien unter Unix). Als Kunde der Klasse muss ich keinen Gehirnzyklus damit verbringen, mich über die Registrierung oder irgendetwas anderes zu wundern, es funktioniert einfach (tm).

http://doc.trolltech.com/4.4/qsettings.html#details

Wenn Sie keine Einstellungen in die Registrierung einfügen, verwenden Sie diese normalerweise hauptsächlich, um aktuelle Windows-Einstellungen abzurufen, Dateizuordnungen zu ändern usw.
Wenn Sie jetzt feststellen müssen, ob Ihre Software bereits installiert ist, können Sie einen minimalen Eintrag in der Registrierung vornehmen , das ist ein Ort, den Sie in jeder Konfiguration wiederfinden können. Oder suchen Sie einen Ordner mit einem bestimmten Namen in den Anwendungsdaten.

Wenn ich mir meinen Ordner "Dokument und Einstellungen" ansehe, sehe ich viele Softwareprogramme, die die Unix-Punktnotation zum Festlegen von Ordnern verwenden: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (etc.)

und in Anwendungsdaten verschiedene Ordner mit Editornamen oder Software-Namen. Zumindest bei tragbaren Anwendungen
scheint dies der aktuelle Trend zu sein ... WinMerge verwendet einen etwas anderen Ansatz: Es speichert Daten in der Registrierung, bietet jedoch den Import und Export von Optionen im Konfigurationsdialog an.

Persönlich habe ich die Registrierung verwendet, um Installationspfade zur Verwendung durch die (Un-) Installationsskripte zu speichern. Ich bin mir nicht sicher, ob dies die einzig mögliche Option ist, schien aber eine vernünftige Lösung zu sein. Dies war für eine App, die natürlich nur unter Windows verwendet wurde.

In .NET besteht wirklich KEIN Bedarf.

Hier sind 2 Beispiele, die zeigen, wie Sie dazu Project-Eigenschaften verwenden.

Diese Beispiele tun dies über die Eigenschaften des Windows-Benutzerprojekts, aber das Gleiche könnte / kann auch über die Anwendung geschehen.

Mehr hier:

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

(zu spät zur Diskussion, aber) Kurze Antwort: Gruppenrichtlinien.

Wenn die IT-Abteilung Ihres Kunden Einstellungen in Bezug auf Windows oder die Komponente (n) erzwingen möchte, in die Sie schreiben oder die Sie bündeln, z. B. eine Verbindungsgeschwindigkeit, eine benutzerdefinierte Fehlermeldung oder einen Datenbankserver, zu dem eine Verbindung hergestellt werden soll, ist dies normalerweise immer noch der Fall Dies erfolgt über Gruppenrichtlinien, die sich endgültig als in der Registrierung gespeicherte Einstellungen manifestieren. Solche Richtlinien werden ab dem Start von Windows oder der Anmeldung des Benutzers erzwungen.

Es gibt Tools zum Erstellen benutzerdefinierter ADMX-Vorlagen, mit denen die Einstellungen Ihrer Komponenten Registrierungsspeicherorten zugeordnet werden können, und die dem Administrator eine gemeinsame Schnittstelle zum Durchsetzen von Richtlinien bieten, die er erzwingen muss, während nur die Einstellungen angezeigt werden, die für die Durchsetzung auf diese Weise von Bedeutung sind.

Ich glaube, dass die Windows-Registrierung eine gute Idee war, aber aufgrund des großen Missbrauchs durch Anwendungsentwickler und der von Microsoft nicht ermutigten / vorgeschriebenen Standardrichtlinien wurde dies zu einem unüberschaubaren Biest. Ich hasse es aus den von Ihnen genannten Gründen, es zu verwenden. Es gibt jedoch einige Fälle, in denen es sinnvoll ist, es zu verwenden:

• Hinterlassen Sie eine Spur Ihrer Anwendung, nachdem Ihre Anwendung deinstalliert wurde (z. B. merken Sie sich die Benutzereinstellungen, falls die Anwendung erneut installiert wird).
• Konfigurationseinstellungen für verschiedene Anwendungen - Komponenten freigeben