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

126

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?

Roddy
quelle
Ich arbeite gerade mit einer Legacy-App, die Informationen in der Registrierung speichert (.NET-App), und das macht mich verrückt.
George Stocker

Antworten:

75
  • 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)
James Curran
quelle
16
Unix: Konfiguration in $ HOME / .your-App gespeichert Dort in einer Iteration gelöst.
Leonel
33
Die Unix-Lösung ist auch alles andere als ideal: $ HOME ist voller Punktedateien, und Sie haben keine Ahnung, was die meisten von ihnen tun.
grep
2
@Leonel XDG schreibt tatsächlich vor, dass Sie Ihre Konfigurationsdateien ablegen müssen $HOME/.config/your-app/, eine Lösung, die erstellt wurde, um das Problem zu lösen, bei dem @grep-Objekte auftreten. Und überraschenderweise hat modernes Linux (und jeder auf dem * BSD, der verrückt genug ist, um GNOME zu verwenden) auch eine Registrierung in der gconfSuite. FOSS züchtet Entscheidungen, das ist sicher;)
new123456
1
@grep, Re " keine Ahnung, was die meisten von ihnen tun ", warum nicht? Außerdem ist das Aufblähen kaum mit dem von Windows vergleichbar.
Pacerier
16

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.

Jimoc
quelle
4
Die Installation erfolgt jedoch häufig unter Administratorsteuerung, während die Aktualisierung der Einstellungen unter Benutzersteuerung erfolgen muss. Stellen Sie sich vor, Sie versuchen, Einstellungen zu aktualisieren - eine App, die unter der Identität des Benutzers ausgeführt wird und in ein Verzeichnis schreiben möchte, das nur für Administratoren zugänglich ist. Dies ist eines der Dinge, die die Registrierung ansprechen soll.
Cheeso
@Cheeso, Die Lösung besteht darin, dass jeder Benutzer eine Kopie der ausführbaren Datei hat. Aus Platzgründen keine echte Kopie, sondern nur eine gefälschte Kopie (Zeiger).
Pacerier
12

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.

Toon Krijthe
quelle
1
Können Sie einen Originallink zu dem Dokument bereitstellen, in dem diese Microsoft-Richtlinie aufgeführt ist? Und wenn Sie Richtlinie sagen, meinen Sie damit, dass Microsoft dies tut, oder meinen Sie, dass Microsoft dies Entwicklern empfiehlt, die Apps für Windows erstellen?
Cheeso
1
ps: raymond Chen von Microsoft hat erklärt, dass INI-Dateien zugunsten der Registrierung veraltet sind, und erklärt, warum. blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx Er gibt auch an, dass XML-Dateien viele der gleichen Nachteile haben wie INI-Dateien.
Cheeso
8
XML-Einstellungsdateien = INI-Dateien, die schwerer zu analysieren sind
Robert Fraser
3
@Fraser Wenn Sie der Meinung sind, dass das Parsen von XML schwierig ist, sind Sie im falschen Geschäft.
SnakeDoc
@SnakeDoc, härter heißt nicht schwieriger. Es bedeutet einfach langsameres Parsen und Verzögerung.
Pacerier
12

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.
AndrewD
quelle
Dies ist eine weitaus vollständigere Antwort als die genehmigte. Danke @AndrewD.
Rotman
8

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.

Angus Glashier
quelle
und es ist großartig, sich selbst zu korrumpieren ... das ist ein Plus. Weniger Arbeit für den Benutzer zu tun ...
SnakeDoc
4

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. :-)

Chris Jester-Young
quelle
4

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.

Martin
quelle
2

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).

JohnIdol
quelle
Dies ist teilweise richtig. Mono hat den Microsoft.win32-Namespace für Registries implementiert - außer, dass er in einer Datei in ~ / .mono / Registry in einer XML-Datei gespeichert und transparent behandelt wird. Wenn Sie nun das XML-Handling für jede App unabhängig von der Plattform
Robert P
Hinweis: Nur verfügbar, wenn Sie eine .NET / Mono-App schreiben.
Robert P
Die Registrierung bietet einen Gewinn: Die Daten sind in einer Multithread-Anwendung leichter zugänglich. Noch wichtiger ist, dass Sie Konfigurationsdaten, die maschinenspezifisch und benutzerspezifisch sind, voneinander trennen können. Ihre Anwendung muss nicht wissen, wer angemeldet ist, wenn sie auf HKEY_CURRENT_USER zugreift. Sie haben jedoch Recht mit der Portabilität.
James
2

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

Rlerallut
quelle
Es scheint, dass die URL nicht mehr funktioniert. Eine Update-Referenz sollte qt-project.org/doc/qt-5/QSettings.html#details
Eineki
0

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.

PhiLho
quelle
Die angezeigte Unix-Punktnotation ist wahrscheinlich darauf zurückzuführen, dass alle diese Beispiele portierte Open-Source-Projekte sind und nicht darauf, dass dies eine bewährte Methode für die Windows-Entwicklung ist.
James
In der Tat habe ich nicht gesagt, dass es sich um "Best Practice" handelt, sondern um gängige Praxis ... :) Die Ordner in Anwendungsdaten / sind / Best Practice, insbesondere für Big Data, aber auch, weil sie einfacher zu sichern sind.
PhiLho
0

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.

Chillysapien
quelle
0

(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.

Spencer
quelle
-1

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
kgiannakakis
quelle
5
Ich bin nicht einverstanden mit Ihnen in Bezug auf Ihren ersten Punkt: "[l] eine Spur Ihrer Anwendung abrufen, nachdem Ihre Anwendung deinstalliert wurde". Ich würde es vorziehen, wenn ich sage "entferne dich von meinem System", dass deine App vollständig konform ist. Ich nehme an, es wäre anders, wenn Sie den Benutzer fragen würden, ob es in Ordnung ist, etwas zurückzulassen, aber selbst dann möchte ich wahrscheinlich, dass es sich um eine gespeicherte Konfigurationsdatei handelt. Ungeachtet der Lizenzierung usw. hätten Sie beim Verkauf Ihres Computers und beim Kauf eines neuen Computers nicht lieber eine Einstellungsdatei, die Sie auf die Neuinstallation laden können, als etwas, das an den Computer gebunden ist, den Sie verkaufen?
AgentConundrum
2
Viele Anwendungen tun dies und Sie können zu Recht sagen, dass dies keine sehr gute Sache ist, insbesondere wenn sie dies ohne die Erlaubnis des Benutzers tun. Es ist jedoch häufig die Funktionalität, die Benutzer von einer Anwendung erwarten (die Mehrheit der Benutzer weiß nicht, was die Registrierung ist). Die Benutzer erwarten nur, dass ihre Einstellungen automatisch wieder hergestellt werden, wenn sie deinstalliert und erneut installiert werden.
kgiannakakis
2
Ich denke, wir haben hier einen Malware-Autor gefunden. Lassen Sie niemals Mist aus Ihrem Programm auf dem System einer anderen Person, wenn diese Sie zur Deinstallation auffordert. Fragen Sie sie zumindest, ob sie sich Einstellungen usw. merken möchten. Tun Sie es niemals einfach. Was ist, wenn Sie einen Lizenzschlüssel speichern und ich meinen Computer verkaufe? Was ist, wenn Ihr Programm Probleme auf meinem Computer verursacht hat und ich versucht habe, es zu deinstallieren, um es zu beheben? Nun, Ihre Registrierungsreste könnten mir viele Probleme bereiten. Tu es einfach nicht. Tu es einfach nicht.
SnakeDoc