Discussion :

[siro1]

Bonjour, je suis acctuellement en train de travailler sur un projet en Winform et j'aimerai utiliser les fichiers ini pour pouvoir sauvegarder ma configuration d'application. Par exemple, si lors de l'utilisation de mon applcation je modifie manuellement la largeur ou position d'une fentre, j'aimerai que ce parametre soit enregistrer de façon à ce que la prochaine fois , lorsque j'ouvrirai cette fenetre , elle soit à la meme position que quand je l'avait ferner. Et ce pour tout autres types de composants tel que les datagrid(longeur, largeur, position des collones . . .)

Quelqu'un aurait-il une methode, simple est efficace ?

Merci

[Médinoc]

Les fichiers ini ont tendance à être passés de mode.
De nos jours, soit on utilise le Registre, soit la configuration XML de .Net (encore peu usitée).

Sinon, je ne sais plus à quoi servent exactement les Settings de Windows Forms, mais ça peut être lié aux histoires de configuration XML. À voir.

[bacelar]

.INI, c'est une vieille méthode qui ne permet pas de faire une distinction entre les configurations au niveau application et celles au niveau de l'utilisateur.
Sommes-nous d'accord que votre sauvegarde est liée à un utilisateur et pas à toute l’application?

Voici un tutoriel pour utiliser les fichiers de configuration .NET en C++/CLI.
http://nico-pyright.developpez.com/t...rationsection/

[Mac LAK]

Pas en base de registre, svp : ça pollue et c'est une utilisation abusive du mécanisme... Surtout que je ne connais pas beaucoup de développeurs qui ont la courtoisie de nettoyer la BDR des scories faites après l'installation lors de la désinstallation du programme.
Au moins, un .INI, ça se nettoie sans chercher trop fort, c'est un des fichiers qui reste après la désinstallation et qui fait gueuler le setup comme quoi il n'a pas pu supprimer le répertoire de l'application.

Le .INI, situé dans le répertoire de l'application elle-même, est la solution la plus simple (cf. WritePrivateProfileString et fonctions associées). Toutefois, comme toute fonctionnalité simple, elle a des inconvénients : notamment, rien ne sera sauvegardé (ni relu !!!) si tu ne le décides pas toi-même.
Sauvegarder la position de la fenêtre ? Quatre valeurs à sauver... La position des splitters ? Encore une valeur... Le dernier chemin d'ouverture de fichier ? Et une chaîne, une ! Etc.

L'autre méthode, c'est le XML : plus lourd à manipuler qu'un .INI, certes, mais derrière, tu as une structure en RAM pouvant être lue et écrite, et surtout, re-sérialisée sur le disque. De plus, en fonction de la technologie / plate-forme, les objets graphiques savent parfois s'initialiser depuis un flux XML, et également se "sauver" dedans. Avec des plate-formes un peu évoluées (.NET, ou encore des RAD comme BCB/Delphi), c'est une méthode plus souple et fiable que le .INI "classique". Par contre, ça demande du boulot pour se mettre le mécanisme dans la tête.

.INI, c'est une vieille méthode qui ne permet pas de faire une distinction entre les configurations au niveau application et celles au niveau de l'utilisateur.

Et les sections, ça sert à quoi d'après toi ??

[bacelar]

Et les sections, ça sert à quoi d'après toi ??

En section par utilisateur ??
Et avec un utilisateur qu'on ne connait ni d'eve ni des dents ?

[Médinoc]

Et les sections, ça sert à quoi d'après toi ??

Ce n'est pas une section qui va te permettre de modifier ton fichier ini dans Program Files en tant qu'utilisateur limité...

[Mac LAK]

En section par utilisateur ??
Et avec un utilisateur qu'on ne connait ni d'eve ni des dents ?

Sûr, c'est très difficile de récupérer le nom de l'utilisateur courant depuis le thread principal, et d'utiliser cet identifiant soit comme préfixe de nom de section, soit de générer un .INI spécifique pour cet utilisateur... Marche aussi avec un XML, d'ailleurs, ça permet de pouvoir supprimer une personnalisation sans devoir perdre les autres ou éditer manuellement le XML.

Après, faut aussi faire attention à ce que l'on stocke dans un fichier de configuration lisible (inclus XML, donc), genre mots de passe en clair et autres informations personnelles.
Il faut aussi relativiser la paranoïa : là, on parle d'une application end-user, où l'on doit "protéger" des données de configuration de façon toute relative, vu que l'on doit juste éviter de mélanger les préférences des personnes qui ont un accès physique à la machine, c'est à dire la propre famille de l'utilisateur...

Ce n'est pas une section qui va te permettre de modifier ton fichier ini dans Program Files en tant qu'utilisateur limité...

Bof... Un coup de GetVersionEx, puis tu prends FOLDERID_ProgramData sous Vista (%APPDATA% en variable d'environnement) si tu veux éviter ce souci. Si cela pouvait être le seul et unique problème lors d'un développement, on serait chez les Bisounours...

[bacelar]

Le truc, c'est qu'avec C++/CLI et des fichiers de configurations en XML, toutes ces cochonneries à faire à la main, et bien d'autre, sont faites de manières TOTALEMENT transparentes.

[Médinoc]

+1 pour Bacelar. L'API de configuration s'occupe elle-même de sauvegarder les paramètres spécifiques à l'utilisateur dans son dossier personnel, et les paramètres des l'EXE dans le répertoire où il se trouve.

@Mac LAK: Par contre, je concède partiellement le point pour le Registre, reconnaissant qu'il est difficile de supprimer les paramètres non-globaux lors de la désinstallation. Le problème, c'est que c'est tout aussi difficile avec des fichiers .ini ou .config, et que RIEN ne couvre les cas extrêmes de désinstallation comme les profils itinérants...

[Mac LAK]

Le truc, c'est qu'avec C++/CLI et des fichiers de configurations en XML, toutes ces cochonneries à faire à la main, et bien d'autre, sont faites de manières TOTALEMENT transparentes.

Mais cela n'est valable qu'en C++/CLI, et pas en C++ "natif".

+1 pour Bacelar. L'API de configuration s'occupe elle-même de sauvegarder les paramètres spécifiques à l'utilisateur dans son dossier personnel, et les paramètres des l'EXE dans le répertoire où il se trouve.

Ce qui peut rendre la désinstallation assez comique d'ailleurs si l'on veut supprimer toute trace de l'application : comment aller supprimer les configurations des AUTRES utilisateurs sans être Administrateur ??
Certes, on limite les scories au dossier personnel de chaque utilisateur, mais bon...

@Mac LAK: Par contre, je concède partiellement le point pour le Registre, reconnaissant qu'il est difficile de supprimer les paramètres non-globaux lors de la désinstallation. Le problème, c'est que c'est tout aussi difficile avec des fichiers .ini ou .config, et que RIEN ne couvre les cas extrêmes de désinstallation comme les profils itinérants...

Jusqu'à XP inclus, si : tu as la possibilité de spécifier quoi supprimer de façon spécifique dans un désinstalleur (et de choisir de ne pas utiliser la BDR à mauvais escient, bien entendu). Pour ma part, je supprime bien sûr toujours mes fichiers de configuration "attendus", et derrière, je supprime "*.*" dans le dossier de l'application. Au passage, je restaure les clés de registre que j'aurais pu modifier manuellement (je garde une copie de la clé d'origine pour ça).

Avec l'obligation d'utiliser le dossier personnel de l'utilisateur depuis Vista, qui peut donc être itinérant, c'est devenu bien plus difficile à faire sans privilèges d'administration... Sur ce point précis, ce n'est pas forcément une excellente chose d'ailleurs, faudra voir ce que ça donne sur Seven d'ailleurs.

[Médinoc]

Ce qui peut rendre la désinstallation assez comique d'ailleurs si l'on veut supprimer toute trace de l'application : comment aller supprimer les configurations des AUTRES utilisateurs sans être Administrateur ??

C'est tautologique, là: Si les autres utilisateurs ont des configurations, c'est que l'application a été installée "pour tout le monde", donc en tant qu'administrateur, donc qu'on la désinstalle en tant qu'administrateur.
Seulement, aussi bien en .ini qu'en .config qu'en Registre, impossible de les trouver et les modifier correctement si le profil est itinérant (possible pour les trois s'ils ne le sont pas, même si c'est un poil plus compliqué niveau registre à cause de la nécessité de charger la ruche de chaque utilisateur).

Certes, on limite les scories au dossier personnel de chaque utilisateur, mais bon...

Et avec le Registre, on limite les scories au HKCU de chaque utilisateur.

Jusqu'à XP inclus, si : tu as la possibilité de spécifier quoi supprimer de façon spécifique dans un désinstalleur (et de choisir de ne pas utiliser la BDR à mauvais escient, bien entendu). Pour ma part, je supprime bien sûr toujours mes fichiers de configuration "attendus", et derrière, je supprime "*.*" dans le dossier de l'application. Au passage, je restaure les clés de registre que j'aurais pu modifier manuellement (je garde une copie de la clé d'origine pour ça).

Avec l'obligation d'utiliser le dossier personnel de l'utilisateur depuis Vista, qui peut donc être itinérant, c'est devenu bien plus difficile à faire sans privilèges d'administration... Sur ce point précis, ce n'est pas forcément une excellente chose d'ailleurs, faudra voir ce que ça donne sur Seven d'ailleurs.

Là, je ne comprends pas ce que tu veux dire, et en quoi XP est différent de Vista sur ce point.

Note: Je parle ici d'une installation et désinstallation locale à un poste, bien entendu. Pour une installation/désinstallation sur tout un domaine, il doit être possible de supprimer la config pour tous les utilisateurs d'un coup...

[Médinoc]

Idéalement, en supposant que les paramètres et/ou l'installation soient forcément locaux, on pourrait regrouper les paramètres utilisateurs avec l'application plutôt que dans leur dossier itinérant:

• Au niveau fichiers, dans un sous-dossier de CSIDL_PROGRAM_FILES (FOLDERID_ProgramFiles) \ Nom Application dont on aurait correctement réglé les droits d'écriture
• Au niveau registre, dans une sous-clé de HKLM\Software\NomÉditeur\NomApplication dont on aurait correctement réglé les droits d'écriture.

[Mac LAK]

C'est tautologique, là: Si les autres utilisateurs ont des configurations, c'est que l'application a été installée "pour tout le monde", donc en tant qu'administrateur, donc qu'on la désinstalle en tant qu'administrateur.

Et tu fais quoi des applications "propres" pouvant être exécutées librement par tous les utilisateurs sans installation explicite pour "Tous" ?

Seulement, aussi bien en .ini qu'en .config qu'en Registre, impossible de les trouver et les modifier correctement si le profil est itinérant (possible pour les trois s'ils ne le sont pas, même si c'est un poil plus compliqué niveau registre à cause de la nécessité de charger la ruche de chaque utilisateur).

D'où l'intérêt, aussi, de ne PAS stocker ces données dans quelque chose de potentiellement mobile. Certes, cela limite l'itinérance des préférences, mais ça augmente la propreté de la machine.

Et avec le Registre, on limite les scories au HKCU de chaque utilisateur.

Tout en plombant les perfs générales de la machine... Au moins, le dossier personnel "n'encombre" pas autre chose que la place sur disque.

Là, je ne comprends pas ce que tu veux dire, et en quoi XP est différent de Vista sur ce point.

Parce que sur XP, tu peux écrire dans le répertoire d'installation de l'application, tout simplement, ce qui limite fortement les prises de tête sur la désinstallation : l'écriture dans le profil de l'utilisateur est alors un choix, et non pas une obligation.

Pour une installation/désinstallation sur tout un domaine, il doit être possible de supprimer la config pour tous les utilisateurs d'un coup...

A part en gardant une trace de TOUS les utilisateurs ayant jamais utilisé le programme sur l'intégralité du domaine pour aller supprimer chaque trace possible sur chaque machine, je ne vois pas trop... Cela reste très lourd à faire, quand même.

Au niveau fichiers, dans un sous-dossier de CSIDL_PROGRAM_FILES (FOLDERID_ProgramFiles) \ Nom Application dont on aurait correctement réglé les droits d'écriture

Bravo, t'as réinventé la méthode usuelle sous Win2k / XP...
Ceci étant dit, je n'arrive pas à comprendre la logique derrière ce blocage sous Vista : OK, ça améliore le confort sur les profils itinérants. Mais ce n'est pas la majorité des profils existants, je pense !
J'aurais préféré un sous-répertoire "obligatoire" par application, avec permissions bien sûr, genre "MonAppli\UserData"... Dossier "normal" (et local) pour les utilisateurs "normaux", et mappé vers le profil de l'utilisateur en cas de profil itinérant. Au moins, cela aurait simplifié la vie de tout le monde, développeurs inclus.

Au niveau registre, dans une sous-clé de HKLM\Software\NomÉditeur\NomApplication dont on aurait correctement réglé les droits d'écriture.

Dans un cas idéal, tu ne devrais JAMAIS avoir besoin de la base de registre, sauf si tu dois modifier des paramètres système (associations de fichiers notamment). La seule exception est la volonté de pouvoir coopérer avec d'autres applications en indiquant, en BDR, le chemin d'installation (ou, bien mieux, de dernière exécution) du programme afin de pouvoir être "trouvé" facilement sans scanner l'intégralité des disques.

[siro1]

Bonjour messieurs,

Donc après ce débat interessant . . . Pour en revenir à ma question principale (sujet de la discution)

Sur quelle méthode devrais-je me baser ?

Merci pour vos réponses

[Médinoc]

Et tu fais quoi des applications "propres" pouvant être exécutées librement par tous les utilisateurs sans installation explicite pour "Tous" ?

Ils sortent du cadre de cette étude: Installés par n'importe qui (ailleurs que dans Program Files), peuvent être désinstallés par n'importe qui pour eux-mêmes.
Là où ça peut devenir marrant, c'est si une application est installée pour "tous" après que certains utilisateurs l'aient installée pour eux-mêmes)

D'où l'intérêt, aussi, de ne PAS stocker ces données dans quelque chose de potentiellement mobile. Certes, cela limite l'itinérance des préférences, mais ça augmente la propreté de la machine.

+1

Tout en plombant les perfs générales de la machine... Au moins, le dossier personnel "n'encombre" pas autre chose que la place sur disque.

Ah, je n'ai rien à répondre à cet argument-là.

Parce que sur XP, tu peux écrire dans le répertoire d'installation de l'application, tout simplement, ce qui limite fortement les prises de tête sur la désinstallation : l'écriture dans le profil de l'utilisateur est alors un choix, et non pas une obligation.

Sous XP, tout le monde est admin? Cool!
Sérieusement, impossible de faire ça sans régler les droits, ce qui revient à la méthode que j'ai évoquée ci-dessous.

A part en gardant une trace de TOUS les utilisateurs ayant jamais utilisé le programme sur l'intégralité du domaine pour aller supprimer chaque trace possible sur chaque machine, je ne vois pas trop... Cela reste très lourd à faire, quand même.

Fermons cette parenthèse.

Bravo, t'as réinventé la méthode usuelle sous Win2k / XP...

Usuelle?
Pour l'instant, le seul programme que j'ai vu faire ça, c'est Steam.

Ceci étant dit, je n'arrive pas à comprendre la logique derrière ce blocage sous Vista

C'est bloqué sous Vista? Comment?
(je suis sincère, là: Je n'ai pas de vista sous la main pour tester)

OK, ça améliore le confort sur les profils itinérants. Mais ce n'est pas la majorité des profils existants, je pense !
J'aurais préféré un sous-répertoire "obligatoire" par application, avec permissions bien sûr, genre "MonAppli\UserData"... Dossier "normal" (et local) pour les utilisateurs "normaux", et mappé vers le profil de l'utilisateur en cas de profil itinérant. Au moins, cela aurait simplifié la vie de tout le monde, développeurs inclus.

+1

Dans un cas idéal, tu ne devrais JAMAIS avoir besoin de la base de registre, sauf si tu dois modifier des paramètres système (associations de fichiers notamment). La seule exception est la volonté de pouvoir coopérer avec d'autres applications en indiquant, en BDR, le chemin d'installation (ou, bien mieux, de dernière exécution) du programme afin de pouvoir être "trouvé" facilement sans scanner l'intégralité des disques.

C'était quand même, à l'époque, la manière recommandée par Microsoft.
Ce qui est pratiquement, en fait, l'unique argument qui pourrait pousser à choisir le Registre plutôt que les fichiers de config pour ses paramètres utilisateur: Tous mes autres arguments étaient neutres.

Mais c'est paradoxal: Sous Windows, on a un Registre alors qu'un exécutable peut retrouver sans problème le répertoire où il se trouve (on va dire OK pour "être trouvé par les autres"), alors que sous *n*x, on n'en a pas, alors qu'un exécutable n'a aucun moyen sûr à 100% de savoir où il est...

[Médinoc]

Bonjour messieurs,

Donc après ce débat interessant . . . Pour en revenir à ma question principale (sujet de la discution)

Sur quelle méthode devrais-je me baser ?

Merci pour vos réponses

On est tombé d'accord sur "pas le Registre". Vu que tu programmes déjà en .net, je te conseille l'API de configuration indiquée par Bacelar.

[Mac LAK]

Sur quelle méthode devrais-je me baser ?

Si tu as beaucoup de choses à sauvegarder, surtout si elles sont plus ou moins pénibles à restaurer, alors un XML.
Si tu es dans un module en C++ natif (non-CLI), genre DLL, ou que tu n'as qu'une ou deux valeurs à sauvegarder/restaurer, alors un .INI sera plus pratique.

Sous XP, tout le monde est admin? Cool!
Sérieusement, impossible de faire ça sans régler les droits, ce qui revient à la méthode que j'ai évoquée ci-dessous.

Je ne crois pas avoir jamais vu un XP où je n'avais pas la possibilité d'écrire dans Program Files, administrateur ou pas, sauf en configuration "Bureau blanc" bien sûr...

Usuelle?
Pour l'instant, le seul programme que j'ai vu faire ça, c'est Steam.

Depuis Vista, pour des raisons de compatibilité, ça se réduit. Mais tu avais pas mal de softs qui faisaient ça, en vrac : IrfanView, FileZilla, UltraEdit, Free Download Manager, InnoSetup, et sûrement pas mal d'autres encore que j'ai oublié.

C'est bloqué sous Vista? Comment?
(je suis sincère, là: Je n'ai pas de vista sous la main pour tester)

Par défaut, tu n'as pas le droit d'écrire dans Program Files avec Vista si tu n'es pas administrateur. Tu as aussi une virtualisation du répertoire qui interdit d'écrire dessus directement.

C'était quand même, à l'époque, la manière recommandée par Microsoft.
Ce qui est pratiquement, en fait, l'unique argument qui pourrait pousser à choisir le Registre plutôt que les fichiers de config pour ses paramètres utilisateur: Tous mes autres arguments étaient neutres.

En fait, MS édicte des "bonnes pratiques"** à chaque version d'OS, notamment pour pallier les abus sur la plate-forme précédente.
A l'origine, utiliser la BDR était prévu pour arrêter la débauche grotesque de .INI dans "C:\Windows", quand ce n'était pas carrément des sections dans le WIN.INI : cela devenait infernal, d'où la BDR... Quelques abus de BDR plus tard, on limite ça en indiquant d'utiliser le répertoire de l'application. De nouveau des abus (propagation de trojans, pollution, etc.), d'où l'utilisation du profil de l'utilisateur.
J'aurais tendance à dire que si certains "développeurs" ne faisaient pas du travail de porc, on n'aurait pas autant de changements lourds dans la manière de "bien se déployer" sous Windows... Tu as d'ailleurs la même chose vis-à-vis de la copie des DLL partagées sous Windows\System(32-64) : là aussi, ça a pas mal évolué depuis Windows 3.1, avec quelques virages à 180° de temps en temps.

** Compte Connect requis.

[Médinoc]

Je ne crois pas avoir jamais vu un XP où je n'avais pas la possibilité d'écrire dans Program Files, administrateur ou pas, sauf en configuration "Bureau blanc" bien sûr...

Et moi, je me rappelle avoir eu besoin de donner les droits sur des dossiers comme celui de Starcraft, sans quoi les sauvegardes ne marchaient pas pour mon petit frère qui n'était pas admin.
Pouvoir écrire dans Program Files quand on n'est pas admin est l'anomalie, pas le comportement normal.

Depuis Vista, pour des raisons de compatibilité, ça se réduit. Mais tu avais pas mal de softs qui faisaient ça, en vrac : IrfanView, FileZilla, UltraEdit, Free Download Manager, InnoSetup, et sûrement pas mal d'autres encore que j'ai oublié.

Par défaut, tu n'as pas le droit d'écrire dans Program Files avec Vista si tu n'es pas administrateur. Tu as aussi une virtualisation du répertoire qui interdit d'écrire dessus directement.

Mais normalement, cela ne change rien au fait qu'un programme d'installation "pour tous" (donc, exécuté par un administrateur) puisse donner les droits sur le sous-dossier en question. J'ai consulté MSDN, la virtualisation ne se produit que si l'ouverture "normale" échoue. De plus, il suffit qu'une application
soit recompilée avec le manifeste pour Vista (ce que Visual 2008 fait par défaut) pour que la virtualisation soit désactivée.

[siro1]

Entre le .ini et le XML, je penche sur le XML mais que pensez vous des fichier .config ?

[Médinoc]

XML peut vouloir dire pas mal de choses.

Le fichier .config est lui-même en XML, notamment.