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 porter 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 - le cas échéant - choisir de placer 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 dans le répertoire Windows.
• Problème: WIN.INI est devenu trop gros.
• Solution (Win31): fichiers INI individuels 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 INI individuels dans le répertoire Windows de l'utilisateur.
• Problème: de nombreuses personnes peuvent partager un dossier Windows, et il devrait de toute façon être en lecture seule.
• Solution (Win95): Registre avec des sections séparées pour chaque utilisateur.
• Problème: le registre est devenu trop volumineux.
• Solution (WinXP): De grands blocs de données individuelles sont déplacés vers le propre 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 une API pour la lire. (Les données en lecture / écriture ou spécifiques à l'utilisateur restent dans le registre)

Pour en venir à 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 que ce ne soit quelque chose comme des associations de fichiers ou des paramètres spécifiques à la machine.

Je viens de l'école de pensée qui dit qu'un programme doit être exécutable de partout où il est installé, que l'installation doit être complètement déplaçable dans une machine, voire sur 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 toute l'installation soit facilement déplacée.

J'utilise beaucoup d'utilitaires plus petits comme des programmes, donc s'il ne peut pas être installé sur une clé USB et branché sur une autre machine et simplement fonctionner, alors ce n'est pas pour moi.

Politique Microsoft:

• Avant Windows 95, nous utilisions des fichiers ini pour les données d'application.
• À l'époque de Windows 95 - XP, 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 la machine. Je ne l'ai jamais aimé car il ralentit et il est presque impossible de trouver ce dont vous avez besoin. C'est pourquoi j'aime les fichiers ini simples ou autres. Vous savez où ils se trouvent (dossier d'application ou dossier utilisateur) afin qu'ils soient facilement portables 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 en sera ainsi" ou parce que vous développez dans un langage plus ancien qui rend l'utilisation de XML plus difficile.

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 la même chose).

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 évitez-les.

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 nécessitaient des 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 gros (et est devenu désordonné).
• Solution: stockez les paramètres dans les fichiers INI dans le même dossier que l'application (Win3.1).
• Problème: nécessite des paramètres spécifiques à l'utilisateur.
• Solution: stockez les paramètres utilisateur dans des fichiers INI spécifiques à l'utilisateur dans le répertoire Windows de l'utilisateur (Win3.11) ou dans des sections spécifiques à l'utilisateur dans le fichier INI de l'application.
• Problème: Sécurité - certains paramètres d'application doivent être en lecture seule.
• Solution: Registre avec sécurité ainsi que sections spécifiques à l'utilisateur et à l'échelle de la machine (Win95).
• Problème: le registre est devenu trop volumineux.
• Solution: le registre spécifique à l'utilisateur a été déplacé vers user.dat dans le propre dossier «Application Data» de l'utilisateur et chargé uniquement lors de la connexion (WinNT).
• Problème: dans les grands environnements d'entreprise, vous vous connectez à plusieurs machines et devez configurer CHACUN.
• Solution: faites la différence entre les profils locaux (Paramètres locaux) et itinérants (Données d'application) (WinXP).
• Problème: Impossible de xcopy déployer ou déplacer 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: il faut encore stocker les données spécifiques à l'utilisateur d'une manière similaire (c'est-à-dire xcopy deploy).
• 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 d'installation 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 soufflé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 lors de l'installation et utilisez les paramètres de l'application 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 éléments les plus récemment utilisés dans le registre Windows? Cela a bien fonctionné pour moi jusqu'à présent.

HKEY-CURRENT-USER est un excellent endroit pour stocker des données utilisateur triviales en petites quantités. C'est pour ça que c'est. Il semble idiot de ne pas l'utiliser aux fins prévues simplement parce que d'autres en ont abusé.

Les paramètres que vous souhaitez voir disponibles dans le profil itinérant d'un utilisateur devraient probablement aller dans le registre, à moins que vous ne souhaitiez réellement chercher à rechercher manuellement le dossier Application Data de l'utilisateur. :-)

Les lectures et écritures du registre sont sûres pour les threads, mais les fichiers ne le sont pas. Cela dépend donc du fait que votre programme soit ou non à thread unique.

Si vous développez une nouvelle application et que vous vous souciez de la portabilité, vous ne devriez JAMAIS stocker de données dans le registre Windows car les autres systèmes d'exploitation n'ont pas de registre (Windows) (note duh - cela peut être évident mais est souvent négligé).

Si vous ne développez que pour les plates-formes Win ... essayez de l'éviter autant que possible. Les fichiers de configuration (éventuellement cryptés) sont une solution bien meilleure. 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).

Un peu 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 fait abstraction du stockage des paramètres (registre sous Windows, fichier de préférences 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 à m'interroger sur le registre ou quoi que ce soit d'autre, ça marche juste (tm).

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

Habituellement, si vous ne mettez 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 nom donné 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 offrant des options d'importation et d'exportation dans la boîte de dialogue de configuration.

Personnellement, j'ai utilisé le registre pour stocker les chemins d'installation à utiliser par les scripts de (dés) installation. Je ne sais pas si c'est la seule option possible, mais cela me semblait être une solution sensée. C'était pour une application qui était uniquement utilisée sous Windows, bien sûr.

Dans .NET, il n'y a jamais vraiment de besoin.

Voici 2 exemples qui montrent comment utiliser les propriétés de projet pour ce faire.

Ces exemples le font par Propriétés du projet utilisateur Windows, mais la même chose pourrait / peut être effectuée par Application.

Plus ici:

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

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

(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, un message d'erreur personnalisé ou un serveur de base de données auquel se connecter, cela reste généralement fait via la stratégie de groupe, qui en fait sa manifestation ultime sous forme de paramètres stockés dans le registre. Ces politiques sont appliquées à partir du moment où Windows démarre ou que l'utilisateur se connecte.

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 stratégies qu'il doit appliquer tout en leur montrant uniquement les paramètres qui sont significatifs pour appliquer de cette manière.

Je pense que le registre Windows était une bonne idée, mais à cause des grands abus de la part des développeurs d'applications et des politiques standard non encouragées / mandatées par Microsoft, il est devenu une bête ingérable. Je déteste l'utiliser pour les raisons que vous avez mentionnées, il y a cependant des occasions où cela a du sens de l'utiliser:

• Laisser une trace de votre application après la désinstallation de votre application (par exemple, mémoriser les préférences de l'utilisateur au cas où l'application serait de nouveau installée)
• Partager les paramètres de configuration entre différentes applications - composants