Lorsque l’option - et pourquoi - devriez vous stocker des données dans le Registre Windows ?

Question

En tant que développeur, outils qui stockent/options de configuration dans le Registre sont le fléau de ma vie. Je ne peux pas facilement suivre les changements dans ces options, ne peut pas facilement port de machine à machine et tout me fait vraiment aspirent pour le bon vieux temps de. Fichiers INI...

Lors de l’écriture de mes propres applications, ce qui - si quelque chose - dois-je choisir pour mettre dans le registre et non dans les fichiers de configuration ancienne et pourquoi ?

Answer 1

• À 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)

Answer 2

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.

Answer 3

Stratégie de Microsoft:

• Avant windows 95, nous avons utilisé les fichiers ini pour les données d'application.
• Dans windows 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 est 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.

Answer 4

Lorsque vous - 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.

Les 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: la 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).
• 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: Utilisez l'ÉLÉMENT de membre 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é.

Answer 5

Le monde va se terminer si vous stockez quelques positions des fenêtres et une liste de la plupart des éléments récemment utilisés dans le Registre Windows ? Il est travaillé OK pour moi jusqu'à présent.

HKEY-CURRENT-USER est un endroit idéal pour stocker les données utilisateur trivial en petites quantités. Voilà à quoi ça sert. Il semble idiot ne pas à utiliser conformément à sa destination, tout simplement parce que d’autres ont abusé.