Hello,

Je suis assez perdu sur le stockage d'infos via les Application Settings.

Je suis sous Visual Studio 2008 Express et je me limite au Framework .NET 2.0.

Je dois sauvegarder les paramètres d'un type d'objet très complexe.

Mon appli charge un plugin qui va exposer des valeurs. je pose des "sondes" pour chaque valeur dont le boulot est de les enregistrer, et d'effectuer divers traitements.

Il peut y avoir un nombre indéfini de Sondes, identifiées par leur nom, et ce pour chaque "plugin".

Et pour chaque "plugin" je veux sauvegarder les infos des sondes associées.

Si j'avais un fichier ini à faire, je le ferai comme ça :

Bref, sauvegarder les paramètres d'une collection d'objet particuliers, liste générée et configurée par l'utilisateur suivant le plugin choisi.

Je dois absolument effectuer des vérifications sur ces valeurs, aussi.

Après avoir exploré les thèmes :

• ConfigurationSection&Co : classe pas dispo dans la version Express
• ConfigurationBase et Bindings : super, mais je ne sais pas comment rendre la collection dépendante d'une autre valeur (ici, le plugin choisi) ni comment intégrer les Bindings (dont je me demande si cela vaut le coup, ici. A la rigueur je peux appeler une fonction de sauvegarde de ces valeurs à la mano...)

Bref, vous feriez comment pour stocker ça, en scope user en plus

Je pourrai utiliser un fichier ini, mais bon, autant faire ça ".net" si possible, d'où ma question...

Merci J'avais regardé ça, mais mon implémentation actuelle dissocie "plugin" et "sonde".

En gros, j'ai un objet plugin que je charge à la volée, et un objet "collection de sondes" dont le contenu change à chaque plugin. Cette collection est une bête liste d'objets d'ailleurs.

A chaque changement de plugin, je vide et recréé le contenu de la collection.

Or, avec la sérialization XML, je ne vois pas comment faire, car j'ai un set de sondes différents par plugin (nombre de plugins et co que je ne supporte pas, c'est ouvert à l'utilisateur).

Ainsi, si je charge le plugin A, je dois récupérer le set de sondes A, idem pour le plugin B...

Et comme je me vois pas déclarer un objet par plugin sans qu'il soit utilisé (dans le style "je bouffe de la ram pour rien"...), je vois pas comment faire

En fait, l'idéal serait quelque chose qui me permette de faire :
"LoadSondesConfiguration(string PluginName)".

Sisi, j'en dispose
 
Je vais creuser avec ce que tu m'as donné. Le coup des clés était ce qui m'a échappé, car effectivement, j'ai un même objet (la liste) qui prends différentes formes suivant la valeur d'un paramètre d'un autre objet.
 
Je vais devoir revoir un peu mon infra coté objet, mais tu m'as donné toutes les infos
 
Merci

Pour upper ce sujet et donner la solution (finalement) retenue : une solution maison.
 
Je n'aime pas le mode XML à la microsoft, je me base donc sur un fichier ini tout simple.
 
Je fais une interface à laquelle tous mes composants voulant voir des données sauvegardées souscrivent. C'est assez simple : un GetValue (int Index) et SetValue (int Index, Object Value). Index, c'est pour identifier sans passer par le nom la valeur sauvegardée. Par exemple, pour un label, je programme dans la classe que Text est la valeur 0 et Tag la valeur 1.
 
Ensuite, je fais un objet Settings, version Singleton, qui va exposer les fonction de sauvegarde/chargement, et surtout une fonction d'enregistrement type Register (Object instance, Section section, String name, Int index) qui me permet de lier mon objet aux valeurs à enregistrer. Le créateur de chaque objet devra juste faire un truc style :
 
Label t = new Label;
Settings.Register(t,"General","t.Text",0);
Settings.Register(t,"General","t.Tag",1);
 
Après, Settings parcourt la liste des objets enregistrés pour la sauvegarde (via l'interface getValue), et pour le chargement, utilise SetValue de l'objet (il a l'interface).  
 
C'est plus câblé que MS, mais ca me permet de maîtriser mieux la chose, d'utiliser un fichier .ini, de gérer les sections facilement. C'est de plus peut-être un peu plus rapide (un fichier ini est moins complexe qu'un XML) et moins verbeux (tout est quasiment situé dans la classe).
 
Comme je n'utilise que des objets "custom" (notamment pour la traduction, je trouve la solution MS vraiment pas pratique pour les traducteurs), ca ne rends pas la chose plus compliquée.
 
bref, certains trouveront ca redondant, d'autres trouveront ça idiot, mais globalement, comme ca me donne plus de contrôle sur la chose, ca reste à la fois simple et efficace.
 
Dommage que MS ait mis en avant le modèle XML, car ce simple choix, tout à fait justifié, empêche les utilisateurs lambda de se plonger dedans facilement...