Quand et pourquoi devriez-vous stocker des données dans le Registre de Windows?

En tant que développeur, les outils qui stockent des informations de configuration/options dans la base de registre sont le fléau de ma vie. Je ne peut pas facilement suivre les modifications apportées à ces options, ne peut pas facilement le port de la machine à la machine, et ça me fait vraiment de la nostalgie pour le bon vieux temps de .Les fichiers INI...

Lors de l'écriture de mes propres applications, ce qui - si quoi que ce soit - dois-je choisir de mettre dans le registre plutôt que dans l'ancienne fichiers de configuration, et pourquoi?

  • Je travaille avec une application héritée maintenant qui stocke des informations dans la base de registre (.NET app), et il me pousse à la noix.
InformationsquelleAutor Roddy | 2008-11-06
  1. 73
    • À l'origine (WIN3), la configuration est stockée dans la VICTOIRE.Fichier INI dans le répertoire windows.
    • Problème: GAGNER.INI a grandi trop grand.
    • Solution (Win31): personne INI fichiers dans le même répertoire que le programme.
    • Problème: ce programme peut être installé sur un réseau et partagée par de nombreuses personnes.
    • Solution(Win311): individuel fichiers INI de l'utilisateur de la Fenêtre de répertoire.
    • Problème: Beaucoup de gens peuvent partager un dossier windows, et il doit être en lecture seule de toute façon.
    • Solution (Win95): Registre avec des sections séparées pour chaque utilisateur.
    • Problème: Registre a grandi trop grand.
    • Solution (WinXP): de Gros blocs de données individuelles déplacé à son propre dossier de Données d'Application.
    • Problème: Bon pour de grandes quantités de données, mais plutôt complexe pour les petites quantités.
    • Solution de (.NET): de petites quantités de fixe, de lire des données stockées dans .config (Xml) des fichiers dans le même dossier que l'application, avec l'API de le lire. (Lecture/écriture ou spécifique à l'utilisateur, les données sont conservées dans la base de registre)
    • Unix: configuration stockée dans $HOME/.votre-application-Il, résolu en une seule itération.
    • Unix solution est loin d'être idéal: $HOME est pléthorique avec dot-fichiers, et vous n'avez aucune idée de ce que la plupart d'entre eux.
    • XDG fait mandats que vous devriez mettre vos fichiers de configuration à l'intérieur de $HOME/.config/your-app/, une solution pour traiter le problème @grep objets. Et, surprise, moderne Linux (et n'importe qui sur les *BSD assez fou pour utiliser GNOME) aussi est un registre dans le gconf suite. Les logiciels libres races choix, c'est sûr 😉
    • Re "aucune idée de ce que la plupart d'entre eux ne", Pourquoi pas? En outre, la météorisation est difficilement comparable avec celle de Windows.
    InformationsquelleAutor James Curran
  2. 16

    Venir à ce à partir d'un point de vue des utilisateurs et des programmeurs point de vue, je dirais il n'y a vraiment pas une bonne exceuse de mettre quelque chose dans le registre, sauf si c'est quelque chose comme les associations de fichiers, ou à la machine, les paramètres spécifiques.

    Je viens de l'école de pensée qui dit que, un programme exécutable à partir de l'endroit où il est installé, que l'installation doit être complètement mobile à l'intérieur d'une machine, ou même sur une autre machine et de ne pas affecter le fonctionnement de celui-ci.

    Toutes les options configurables, ou que la dll, etc, si elles ne sont pas partagées doivent résider dans un sous-répertoire du répertoire d'installation, de sorte que l'ensemble de l'installation est facilement déplacé.

    J'utilise beaucoup d'électricité réduite de programmes de ce genre, donc si il ne peut pas être installé sur une clé usb et branché sur une autre machine et il suffit d'exécuter, alors ce n'est pas pour moi.

    • Mais l'installation est souvent fait sous contrôle d'administration, tandis que les paramètres de mise à jour doit être fait sous contrôle de l'utilisateur. Imaginez que vous essayez de mettre à jour les paramètres d'une application qui s'exécute sous l'identité de l'utilisateur qui veut écrire dans un répertoire qui est réservé à l'admin-accès uniquement. C'est l'une des choses que le registre est destiné à l'adresse.
    • La solution, c'est à chaque utilisateur de disposer d'une copie de l'exécutable. Pour économiser de l'espace, pas une copie, mais juste un faux copie (pointeur).
    InformationsquelleAutor Jimoc
  3. 12

    Stratégie de Microsoft:

    • Avant windows 95, nous avons utilisé les fichiers ini pour les données d'application.
    • Dans les fenêtres 95 - XP époque, nous avons utilisé la base de registre.
    • À partir de windows Vista, nous utilisons les fichiers ini, bien qu'ils soient désormais basé sur xml.

    Le registre dépend de la machine. Je n'ai jamais aimé parce que sa arriver à ralentir et il est presque imposible de trouver la chose dont vous avez besoin. C'est pourquoi j'aime simple ini ou d'autres fichiers de paramètres. Vous savez où ils sont (dossier de l'application ou d'un dossier utilisateur), de sorte qu'ils sont faciles portable, et lisible par l'homme.

    • Pouvez-vous fournir un lien pour la doc que les états de cette politique de microsoft? Et quand vous dites que la politique, voulez-vous dire, c'est ce que fait Microsoft, ou voulez-vous dire c'est ce que Microsoft recommande aux développeurs qui construisent des applications pour Windows?
    • ps: raymond Chen, de Microsoft, a déclaré que les fichiers INI sont abandonnés en faveur de la Greffe, et explique pourquoi. blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx Il déclare également que les fichiers XML ont beaucoup des mêmes inconvénients que les fichiers ini.
    • XML des fichiers de paramètres = INI fichiers qui sont plus difficiles à analyser
    • si vous pensez que l'analyse de XML est difficile, vous êtes dans la mauvaise entreprise.
    • Plus difficile ne signifie pas plus difficile. Cela signifie simplement plus lent de l'analyse et du décalage horaire.
    • Quoi? L'analyse de XML peut être très rapide en effet (aussi rapide que votre disque va lire le fichier).
    • Analyse XML est l'un des plus faibles jamais. Les fichiers Ini et simple des fichiers au format de grandeur plus rapide.
    • Qui sonne comme un non fondées, affirmation sans fondement. Cela dépendra de scénario, et comment grand les dossiers sont censés être, et bien sûr la vitesse de vos disques. Même Microsoft semble recommander System.Configuration espace de noms de ces jours, qui est basé sur XML.

    InformationsquelleAutor Toon Krijthe
  4. 11

    Quand - Vous êtes forcé à cause de l'héritage de l'intégration ou parce que votre client sysadmin dit "il doit être" ou parce que vous êtes en développement dans un ancien langage qui rend plus difficile l'utilisation de XML.

    Pourquoi - Principalement parce que le registre n'est pas aussi portable que de la copie d'un fichier de configuration qui est assis à côté de la demande (et est appelée à peu près la même).

    Si vous êtes en utilisant .Net2+ vous avez de l'Application.Config et de l'Utilisateur.Les fichiers de configuration et vous n'avez pas besoin d'enregistrer la DLL dans le registre afin de rester loin de lui.

    Fichiers de configuration ont leurs propres problèmes (voir ci-dessous), mais ceux-ci peuvent être codés en autour de vous et vous pouvez modifier votre architecture.

    • Problème: les Applications nécessaires des paramètres configurables.
    • Solution: Stocker les paramètres dans un fichier (GAGNER.INI) dans le dossier Windows - utiliser des têtes de sections pour regrouper des données (Win3.0).
    • Problème: GAGNER.Fichier INI a grandi trop gros (et obtenu salissant).
    • Solution: Stocker les paramètres dans les fichiers INI dans le même dossier que l'application (Win3.1).
    • Problème: Besoin de paramètres spécifiques à l'utilisateur.
    • Solution: Stocker de l'utilisateur-paramètres spécifiques à l'utilisateur des fichiers INI de l'utilisateur de la Fenêtre de répertoire (Win3.11), ou de l'utilisateur à des sections spécifiques de l'application fichier INI.
    • Problème: Sécurité - certains paramètres de l'application doivent être en lecture seule.
    • Solution: Registre de sécurité spécifiques à l'utilisateur et de la machine à l'échelle des sections (Win95).
    • Problème: Registre a grandi trop grand.
    • Solution: registre spécifiques à l'Utilisateur déplacé à l'utilisateur.dat dans de l'utilisateur dossier "Application Data" et chargé uniquement lors de la connexion (WinNT).
    • Problème: Dans les grandes entreprises environnements de vous connecter sur plusieurs machines et de définir CHACUN d'eux.
    • Solution: faire la différence entre le niveau local (Local Settings) et de l'itinérance (Données d'Application) et des profils (WinXP).
    • Problème: Impossible de xcopy déployer ou déplacer des applications comme le reste de .Net.
    • Solution: APP.CONFIG XML fichier dans le même dossier que l'application , facile à lire, facile à manipluate, facile à déplacer, peuvent suivre en cas de changement de (.Net1).
    • Problème: Encore besoin de stocker des données spécifiques à l'utilisateur dans un même (c'est à dire xcopy déployer) manière.
    • Solution: l'UTILISATEUR.CONFIG fichier XML dans le local de l'utilisateur ou d'itinérance dossier et fortement typé (.Net2).
    • Problème: les fichiers de configuration sont sensibles à la casse (pas intuitif pour les humains), besoin très spécifique ouvrir/fermer "tags", les chaînes de connexion ne peut pas être définie au moment de l'exécution, les projets d'installation ne peut pas écrire des paramètres (aussi facilement que le registre ne peut pas déterminer facilement l'utilisateur.le fichier de configuration et les paramètres de l'utilisateur sont soufflés à chaque nouvelle révision installé.
    • Solution: Utiliser l'ÉLÉMENT membres pour définir les chaînes de connexion au moment de l'exécution, écrire du code dans une classe du programme d'installation de modifier l'Application.Config lors de l'installation et l'utilisation de l'application paramètres comme paramètres par défaut si l'utilisateur n'est pas trouvé.
    InformationsquelleAutor AndrewD
  5. 8

    Va le monde à la fin si vous stockez quelques positions de la fenêtre et une liste de la plupart des éléments récemment utilisés dans le registre de Windows? Il a travaillé très bien pour moi jusqu'à présent.

    HKEY-CURRENT-USER est un endroit idéal pour stocker trivial données de l'utilisateur en petites quantités. C'est ce qu'il est. Il semble idiot de ne pas l'utiliser pour son usage prévu, juste parce que d'autres ont abusé d'elle.

    • et c'est génial à la corruption elle-même... c'est un plus. Moins de travail pour l'utilisateur de le faire...
    InformationsquelleAutor Angus Glashier
  6. 4

    Les paramètres que vous souhaitez avoir à disposition dans un profil itinérant devrait probablement aller dans le registre, sauf si vous voulez vraiment aller à l'effort de recherche pour l'Application de l'utilisateur des Données de dossier en main. 🙂

    InformationsquelleAutor Chris Jester-Young
  7. 4

    Registre des lectures et écritures sont thread-safe, mais les fichiers ne le sont pas. Donc, cela dépend de si oui ou non votre programme est mono-thread.

    InformationsquelleAutor Martin
  8. 2

    Si vous développez un nouveau programme et vous vous souciez de la portabilité, vous devriez JAMAIS stocker des données dans le registre de windows depuis les autres OS n'ont pas (windows) registre (duh remarque - ce qui peut être évident, mais il obtient souvent négligé).

    Si vous êtes seulement de développer pour Gagner des plates-formes ... essayer de l'éviter autant que possible. Les fichiers de configuration (éventuellement crypté) sont une manière de trouver la meilleure solution. Il n'y a pas de gain de stockage des données dans la base de registre - (stockage isolé est une bien meilleure solution, par exemple, si vous êtes en utilisant .NET).

    • Cela est en partie vrai. Mono a mis en œuvre le Microsoft.win32 espace de noms pour les registres - sauf qu'il stocke dans un fichier dans ~/.mono/Registre dans un fichier xml, et il est traité de manière transparente. Maintenant, si vous pouviez tourner la gestion xml pour toute application, indépendamment de la plate-forme...
    • Remarque: disponible uniquement si vous êtes en train de rédiger un .NET/Mono app.
    • Le registre ne se permettre un gain: les données sont plus facilement accessibles, dans une application multi-thread. Plus important encore, il vous permet de séparer les données de configuration spécifique à l'appareil vs spécifique à l'utilisateur. Votre demande n'a pas à être au courant de qui est connecté lorsqu'il accède à la clé de registre HKEY_CURRENT_USER. Vous avez raison au sujet de la portabilité, bien que.
    InformationsquelleAutor JohnIdol
  9. 2

    Légèrement hors-sujet, mais depuis que je vois des personnes concernées au sujet de la portabilité, la meilleure approche que j'ai jamais utilisé Qt est la classe QSettings. Il fait abstraction du stockage des réglages de la base de registre sur Windows, XML fichier de préférences sur Mac OS et fichiers Ini sur Unix). En tant que client de la classe, je n'ai pas à dépenser un cerveau cycle demandais à propos de la base de registre ou autre chose, ça marche (tm).

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

    InformationsquelleAutor rlerallut
  10. 0

    Habituellement, si vous ne mettez pas les paramètres dans la base de registre, vous l'utilisez principalement pour suivre l'évolution des paramètres de Windows, modifier les associations de fichiers, etc.

    Maintenant, si vous avez besoin de détecter si votre logiciel est déjà installé, vous pouvez faire un minimum d'entrée dans la base de registre, c'est un endroit où vous pourrez les trouver dans une config. Ou de recherche d'un dossier du nom donné dans les Données de l'Application.

    Si je regarde mon Document et les Paramètres de dossier, je vois beaucoup de logiciels Unix à l'aide de la notation de point pour le réglage des dossiers:
    .p4qt
    .sqlworkbench
    .squirrel-sql
    .SunDownloadManager
    .xngr
    .antexplorer
    .assistant
    .CodeBlocks
    .dbvis
    .gimp-2.4
    .jdictionary
    .jindent
    .jogl_ext (etc.)

    et dans les Données de l'Application, différents dossiers avec l'éditeur des noms ou des noms des logiciels. Regarde comme étant la tendance actuelle, au moins parmi les applications portables...

    WinMerge utilise une approche légèrement différente, le stockage des données dans la base de registre, mais offrant l'Importation et l'Exportation des options dans la boîte de dialogue de configuration.

    • Unix point notation que vous voyez est probablement parce que tous ces exemples sont portés les projets open-source, non pas parce que c'est l'une des meilleures pratiques de développement de Windows.
    • En effet, je n'ai pas dit que c'était la "meilleure pratique", mais la pratique courante... 🙂 Les dossiers de demande de données /sont/ les meilleures pratiques, en particulier pour le big data, mais aussi parce qu'ils sont plus faciles à sauvegarder.
    InformationsquelleAutor PhiLho
  11. 0

    Personnellement, j'ai utilisé le registre pour stocker les chemins d'installation pour une utilisation par les nations unies (un)installer les scripts. Je ne sais pas si c'est la seule option possible, mais semblait être une solution sensée. C'était pour une application qui a été le seul à l'utiliser sur Windows, bien sûr.

    InformationsquelleAutor chillysapien
  12. 0

    Dans .NET il n'est vraiment PAS toujours une nécessité.

    Voici 2 exemples qui montrent comment utiliser le Projet proerties à faire de ce.

    Ces exemples ce faire, l'Utilisateur de Windows Propriétés du Projet, mais la même chose pourrait/qui peut être fait par l'Application.

    Plus ici:

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

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

    InformationsquelleAutor
  13. 0

    (à la fin de la discussion mais) Réponse Courte: la Stratégie de Groupe.

    Si votre informatique du client souhaite appliquer des paramètres liés à Windows ou les composant(s) que vous avez écrit ou groupée, comme un lien de vitesse, ou un message d'erreur personnalisé, ou un serveur de base de données pour se connecter, ce n'est encore fait généralement via la Stratégie de Groupe, ce qui rend sa manifestation ultime que les paramètres stockés dans le registre. Ces politiques sont appliquées à partir de l'heure de démarrage de Windows ou de l'utilisateur.

    Il existe des outils pour créer des ADMX modèles qui permet de cartographier vos composants à des emplacements du registre, et de donner à l'administrateur d'une interface commune pour faire appliquer les politiques (s)dont il a besoin pour faire respecter tout en leur montrant uniquement les paramètres qui sont pertinents pour appliquer cette façon.

    InformationsquelleAutor Spencer
  14. -1

    Je crois que le Registre de Windows est une bonne idée, mais en raison de la grande abus de la part de développeurs d'applications standard et de politiques qui ne sont pas encouragée, mandaté par Microsoft a grandi pour devenir ingérable bête. J'ai hate de l'utiliser pour les raisons que vous avez mentionnées, il y a cependant dans certains cas il est logique de l'utiliser:

    • Laisser une trace de votre demande après votre demande a bien été désinstallé (par exemple, mémoriser les préférences de l'utilisateur dans le cas où l'application est installée de nouveau)
    • Partager les paramètres de configuration entre les différentes applications, les composants
    • Je suis en désaccord avec vous concernant votre premier point, "[l]eaving une trace de votre demande après votre demande a bien été désinstallé". Je préfèrerais que si je dis "retirez-vous de mon système" que votre application se conformer complètement. Je suppose que ce serait différent si vous avez été demander à l'utilisateur si il est ok pour laisser quelque chose derrière, mais même alors, je serais probablement voulez qu'il soit enregistré au fichier de configuration. Les licences, etc. nonobstant, si vous vendez votre ordinateur et d'en acheter un nouveau, n'auriez-vous pas plutôt un fichier de paramètres que vous pouvez charger sur la nouvelle installation, plutôt que quelque chose lié à l'ordinateur que vous vendez?
    • De nombreuses applications de ce faire, et vous avez raison de dire que ce n'est pas une très bonne chose, surtout si ils le font sans l'autorisation de l'utilisateur. Toutefois, il est souvent la fonctionnalité que les utilisateurs s'attendent à partir d'une application (la majorité de l'utilisateur ne sait pas ce que le registre est). Les utilisateurs s'attendent à trouver leur paramètres de l'auto-magiquement de nouveau de retour, quand ils désinstaller et installer à nouveau.
    • Je pense que nous avons trouvé un malware auteur ici. Ne jamais laisser de la merde à partir de votre programme sur le système de quelqu'un si on vous a demandé de désinstaller. Au moins leur demander si ils veulent se rappeler les réglages, etc. Ne jamais juste de le faire. Que faire si vous stockez une clé de licence et je vends mon ordinateur? Que faire si votre programme a été à l'origine des problèmes sur mon ordinateur, et j'ai essayé de le désinstaller pour le fixer? Eh bien, votre base de registre restes pourrait me causer beaucoup de problèmes. Il suffit de ne pas le faire. Il suffit de ne pas.
    InformationsquelleAutor kgiannakakis