Quand - et pourquoi - devez-vous stocker des données dans le Registre Windows?
En tant que développeur, les outils qui stockent la configuration/les options dans le registre sont le fléau de ma vie. Je ne peux pas facilement suivre les modifications apportées à ces options, je ne peux pas les transférer facilement d'une machine à l'autre, et tout cela me fait vraiment aspirer au bon vieux temps des fichiers .INI ...
Lors de l'écriture de mes propres applications, que dois-je choisir si je veux mettre dans le registre plutôt que dans des fichiers de configuration à l'ancienne, et pourquoi?
- À l'origine, la configuration (WIN3) était stockée dans le fichier WIN.INI du répertoire Windows.
- Problème: WIN.INI est devenu trop gros.
- Solution (Win31): fichiers individuels INI dans le même répertoire que le programme.
- Problème: ce programme peut être installé sur un réseau et partagé par de nombreuses personnes.
- Solution (Win311): fichiers individuels INI dans le répertoire Windows de l'utilisateur.
- Problème: de nombreuses personnes peuvent partager un dossier Windows et il doit de toute façon être en lecture seule.
- Solution (Win95): Registre avec des sections distinctes pour chaque utilisateur.
- Problème: le registre est devenu trop grand.
- Solution (WinXP): de grands blocs de données individuelles ont été déplacés vers le dossier Application Data de l'utilisateur.
- Problème: bon pour de grandes quantités de données, mais plutôt complexe pour de petites quantités.
- Solution (.NET): petites quantités de données fixes en lecture seule stockées dans des fichiers .config (Xml) dans le même dossier que l'application, avec API pour les lire. (Les données spécifiques en lecture/écriture ou utilisateur restent dans le registre)
En venant à la fois du point de vue de l'utilisateur et du point de vue des programmeurs, je dois dire qu'il n'y a vraiment pas de bonne excuse pour mettre quelque chose dans le registre à moins qu'il s'agisse d'associations de fichiers ou de paramètres spécifiques à la machine.
Je viens de l'école de pensée qui dit qu'un programme doit être exécutable de n'importe où il est installé, que l'installation doit être complètement déplaçable à l'intérieur d'une machine, ou même vers une autre machine et ne pas affecter son fonctionnement.
Toutes les options configurables, ou les DLL requises, etc., si elles ne sont pas partagées, doivent résider dans un sous-répertoire du répertoire d'installation, afin que l'installation entière soit facilement déplacée.
J'utilise beaucoup de petits utilitaires comme des programmes, donc s'il ne peut pas être installé sur une clé USB et branché sur une autre machine et juste fonctionner, alors ce n'est pas pour moi.
Politique Microsoft:
- Avant Windows 95, nous utilisions des fichiers ini pour les données d'application.
- Dans les fenêtres 95 - XP ère, nous avons utilisé le registre.
- Depuis Windows Vista, nous utilisons des fichiers ini bien qu'ils soient désormais basés sur XML.
Le registre dépend de l'ordinateur. Je ne l'ai jamais aimé parce que ça ralentit et il est presque impossible de trouver la chose dont vous avez besoin. C'est pourquoi j'aime les simples ini ou autres fichiers de configuration. Vous savez où ils se trouvent (dossier d'application ou dossier utilisateur), ils sont donc faciles à transporter et lisibles par l'homme.
Quand - Vous êtes obligé de le faire en raison de l'intégration héritée ou parce que l'administrateur système de votre client dit "il doit en être ainsi" ou parce que vous développez dans un langage plus ancien qui rend plus difficile l'utilisation de XML.
Pourquoi - Principalement parce que le registre n'est pas aussi portable que la copie d'un fichier de configuration qui se trouve à côté de l'application (et s'appelle presque le même).
Si vous utilisez .Net2 +, vous avez des fichiers App.Config et User.Config et vous n'avez pas besoin d'enregistrer les DLL dans le registre, alors restez à l'écart.
Les fichiers de configuration ont leurs propres problèmes (voir ci-dessous), mais ceux-ci peuvent être codés et vous pouvez modifier votre architecture.
- Problème: les applications avaient besoin de paramètres configurables.
- Solution: stockez les paramètres dans un fichier (WIN.INI) dans le dossier Windows - utilisez les en-têtes de section pour regrouper les données (Win3.0).
- Problème: le fichier WIN.INI est devenu trop volumineux (et est devenu désordonné).
- Solution: stockez les paramètres dans des fichiers INI dans le même dossier que l'application (Win3.1).
- Problème: besoin de paramètres spécifiques à l'utilisateur.
- Solution: stockez les paramètres utilisateur dans des fichiers spécifiques à l'utilisateur INI dans le répertoire Windows de l'utilisateur (Win3.11) ou dans des sections spécifiques à l'utilisateur dans l'application INI .
- Problème: Sécurité - certains paramètres d'application doivent être en lecture seule.
- Solution: Registre avec sécurité ainsi que des sections spécifiques à l'utilisateur et à l'échelle de la machine (Win95).
- Problème: le registre est devenu trop grand.
- Solution: le registre spécifique à l'utilisateur a été déplacé vers user.dat dans le dossier "Application Data" de l'utilisateur et n'a été chargé qu'à la connexion (WinNT).
- Problème: dans les grands environnements d'entreprise, vous vous connectez à plusieurs machines et devez configurer CHAQUE UNE.
- Solution: faites la différence entre les profils local (Paramètres locaux) et itinérant (Données d'application) (WinXP).
- Problème: impossible de déployer ou de déplacer xcopy des applications comme le reste de .Net.
- Solution: fichier XML APP.CONFIG dans le même dossier que l'application -, facile à lire, facile à manipuler, facile à déplacer, peut suivre s'il est modifié (.Net1).
- Problème: vous devez toujours stocker les données spécifiques à l'utilisateur de manière similaire (c'est-à-dire déployer xcopy).
- Solution: fichier XML USER.CONFIG dans le dossier local ou itinérant de l'utilisateur et fortement typé (.Net2).
- Problème: les fichiers CONFIG sont sensibles à la casse (pas intuitifs pour les humains), nécessitent des "balises" d'ouverture/fermeture très spécifiques, les chaînes de connexion ne peuvent pas être définies au moment de l'exécution, les projets de configuration ne peuvent pas écrire les paramètres (aussi facilement que le registre), ne peuvent pas facilement déterminer Le fichier user.config et les paramètres utilisateur sont supprimés à chaque nouvelle révision installée.
- Solution: utilisez le membre ITEM pour définir des chaînes de connexion au moment de l'exécution, écrivez du code dans une classe Installer pour modifier App.Config pendant l'installation et utilisez les paramètres de l'application comme valeurs par défaut si aucun paramètre utilisateur n'est trouvé.
Le monde va-t-il se terminer si vous stockez quelques positions de fenêtre et une liste des derniers éléments utilisés dans le registre Windows? Jusqu'à présent, cela a bien fonctionné pour moi.
HKEY-CURRENT-USER est un excellent endroit pour stocker des données utilisateur triviales en petites quantités. C'est pour ça. Il semble stupide de ne pas l'utiliser aux fins prévues simplement parce que d'autres en ont abusé.
Les lectures et écritures du registre sont threadsafe mais les fichiers ne le sont pas. Cela dépend donc du fait que votre programme soit monothread ou non.
Les paramètres que vous souhaitez mettre à disposition dans le profil itinérant d'un utilisateur doivent probablement être enregistrés dans le registre, sauf si vous souhaitez réellement rechercher manuellement le dossier Application Data de l'utilisateur. :-)
Légèrement hors sujet, mais comme je vois des gens préoccupés par la portabilité, la meilleure approche que j'ai jamais utilisée est la classe QSettings de Qt. Il résume le stockage des paramètres (registre sous Windows, fichier de préférence XML sous Mac OS et fichiers Ini sous Unix). En tant que client de la classe, je n'ai pas à passer un cycle cérébral à me poser des questions sur le registre ou quoi que ce soit d'autre, ça fonctionne juste (tm).
Si vous développez une nouvelle application et que vous vous souciez de la portabilité, vous devez JAMAIS stocker les données dans le registre Windows car les autres systèmes d'exploitation n'ont pas de registre (windows) ( duh note - cela peut être évident mais est souvent négligé).
Si vous ne développez que pour les plates-formes Win ... essayez d'éviter autant que possible. Les fichiers de configuration (éventuellement cryptés) sont une bien meilleure solution. Il n'y a aucun gain à stocker des données dans le registre - (le stockage isolé est une bien meilleure solution par exemple si vous utilisez .NET).
(en retard à la discussion mais) Réponse courte: stratégie de groupe.
Si le service informatique de votre client souhaite appliquer des paramètres liés à Windows ou au (x) composant (s) que vous écrivez ou regroupez, comme une vitesse de liaison, ou un message d'erreur personnalisé, ou un serveur de base de données auquel se connecter, c'est toujours généralement fait via la stratégie de groupe, qui fait sa manifestation ultime en tant que paramètres stockés dans le registre. Ces politiques sont appliquées dès le démarrage de Windows ou la connexion de l'utilisateur.
Il existe des outils pour créer des modèles ADMX personnalisés qui peuvent mapper les paramètres de vos composants aux emplacements de registre et donner à l'administrateur une interface commune pour appliquer les politiques qu'il doit appliquer tout en ne leur montrant que les paramètres significatifs à appliquer de cette façon.
Habituellement, si vous ne placez pas de paramètres dans le registre, vous l'utilisez principalement pour obtenir les paramètres Windows actuels, modifier les associations de fichiers, etc.
Maintenant, si vous devez détecter si votre logiciel est déjà installé, vous pouvez faire une entrée minimale dans le registre, c'est un emplacement que vous pouvez retrouver dans n'importe quelle configuration. Ou recherchez un dossier du même nom dans Application Data.
Si je regarde mon dossier Document and Settings, je vois beaucoup de logiciels utilisant la notation par points Unix pour définir les dossiers: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (etc.)
et dans Application Data, divers dossiers avec des noms d'éditeurs ou des noms de logiciels. On dirait que c'est la tendance actuelle, au moins parmi les applications portables ...
WinMerge utilise une approche légèrement différente, stockant les données dans le registre, mais proposant des options d'importation et d'exportation dans la boîte de dialogue de configuration.
Dans .NET, il n'y a vraiment jamais besoin.
Voici 2 exemples qui montrent comment utiliser les propriétés du projet pour ce faire.
Ces exemples le font par les propriétés du projet utilisateur Windows, mais la même chose peut/peut être effectuée également par l'application.
Plus ici:
Personnellement, j'ai utilisé le registre pour stocker les chemins d'installation à utiliser par les scripts d'installation (dé). Je ne sais pas si c'est la seule option possible, mais cela semblait être une solution sensée. C'était pour une application qui était uniquement utilisée sur Windows bien sûr.