Appli et répertoire des données (user settings)

cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 - 23 déc. 2013 à 19:16
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 - 27 déc. 2013 à 03:56
Bonjour,

J'ai créé une application qui possède des Settings, histoire de conserver ses paramètres.
Le fichier de ces Settings, user.config (fichier a structure xml) se retrouve dans le répertoire :
C:\Users\Jack\AppData\Local\xxxx\MonAppli.exe_Url_ullhqdzxi2kwrzovontxgtftfqz3s0iw\1.0.0.0
où :
"xxxx" est l'espace de noms racine fourni dans les paramètres de l'appli
"MonAppli.exe" est le nom de mon appli (non, vrai ?)
"1.0.0.0" la version

Ma question :
Pourquoi est-ce que je me retrouve avec cette suite de lettres/chiffres dans le nom du répertoire et pourquoi n'est-il pas tout simple ?
Et comment y remédier ?
Une structure plus simple comme celle-ci me plairait plus mieux :
C:\Users\Jack\AppData\Local\xxxx\MonAppli\1.0.0.0

Même après avoir installé proprement mon logiciel, je me retrouve avec ce genre de répertoire à rallonge et pas beau.

4 réponses

cs_Robert33 Messages postés 834 Date d'inscription samedi 15 novembre 2008 Statut Membre Dernière intervention 14 janvier 2017 33
24 déc. 2013 à 07:19
Bonjour

L'explication est simple,
Il existe 2 types de settings: User et Application
Les "user settings" sont par définition par utilisateur, donc le dotnet va les stocker dans le répertoire User\...
Ils peuvent être différents d'une version de programme à une autre, d'où l'ajout du numéro de version
Et maintenant, suppose que je génère moi aussi un "MonAppli.exe", il faut bien que le dotnet les différenties, d'où l'ajout de la signature de l'application.

Si tu veux avoir des "Settings" commun à tous les utilisateurs utilise le type "Application Setting" ils seront modifiables dans le fichier Monappli.exe.config que tu devras livrer avec ton application
Si non tu dois fournir dans ton application la gestion des "User Settings" via un menu Outil/Paramètre par exemple.
0
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 79
24 déc. 2013 à 11:24
Merci Robert.
M'en va tester ça après les fêtes ... que je te souhaite familiales et joyeuses
0
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 79
26 déc. 2013 à 18:20
Après approfondissement du sujet :

"Et maintenant, suppose que je génère moi aussi un "MonAppli.exe", il faut bien que le dotnet les différenties, d'où l'ajout de la signature de l'application."
A quoi sert la définition de "l'espace de noms racine" si on est obligé de supporter une couche supplémentaire d'ID ...
C'est bien lourd ...

"utilise le type "Application Setting" ils seront modifiables dans le fichier Monappli.exe.config"
En effet, les paramètres définis avec une portée "Application" se retrouvent dans App.Config, mais dans le répertoire de l'exécutable, donc en lecture seule puisqu'un user lambda n'est pas autorisé à modifier les fichiers placés dans cette arborescence (post XP).
Donc, par voix de conséquence, l'application ne peut pas modifier le contenu de ces variables (de toute façon, définies autoritairement en ReadOnly dans l'application).
Stocker des paramètres : c'est quand même mon but premier.

Pour l'instant, la seule solution que j'envisage pour :
- Avoir une arborescence propre (sans signature de l'appli)
- Stocker des données vivantes dans l'appli
sera d'abandonner la gestion de Settings standard (pour une fois qu'il y avait un truc bien pensé) :
- gérer moi-même la création de l'arborescence dans "C:\Users\Jack\AppData\Local\xxxx\MonAppli\Version"
- d'y stocker un fichier XML que je vais devoir gérer à la main dans l'appli.

Vraiment lourdingue, ce .Net.
Merci Robert pour cette idée qu'y ne me convient pas.
0
cs_Robert33 Messages postés 834 Date d'inscription samedi 15 novembre 2008 Statut Membre Dernière intervention 14 janvier 2017 33
26 déc. 2013 à 19:30
Bonsoir

Ce serait bien dommage de tout gérer manuellement, alors que le dotnet peut le faire.

C'est à dessein que les "Settings Application" se trouvent dans le fichier de configuration, ils sont normalement gérés par un administrateur, et se doivent être identiques pour tous les utilisateurs.

Pour les "Settings User" tu n'as pas à gérer le fichier manuellement, le dotnet possède des méthode pour cela, et l'endroit ou il range le fichier n'a pas d'importance.
Crée tes paramètres et gère les directement dans ton code.

ex, soit un setting User "DernierPassage" de type Date
pour en récupérer la valeur :
Dim DateDernierPassage As Date = WindowsApplication1.My.MySettings.Default.DernierPassage

Pour la modifier
WindowsApplication1.My.MySettings.Default.DernierPassage = Date.Now
WindowsApplication1.My.MySettings.Default.Save()

Et voila, pas besoin de savoir ou c'est rangé, le principal étant de pouvoir agir sur les valeurs par utilisateur.

Cela dit si tu veux modifier des paramètres de type application alors je suis d'accord avec toi, ce serait bien que le dotnet le permette, en général j'utilise une clef de registre.

0
cs_Jack Messages postés 14006 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 79
27 déc. 2013 à 03:56
Oui, je suis bien d'accord avec toi, les "User Settings" sont hyper pratiques sauf qu'ils se retrouvent dans une arborescence qui ne me convient pas (celle qui contient la signature de l'appli).

Pour t'expliquer, mon application sera installée sur des machines qui sont suivies de prêt par les services informatiques des usines (secteurs pointus) où il tournera et dans la procédure, je dois écrire en dur le nom des répertoires créés.
Si, par programme, je ne peux pas maitriser le nom du répertoire, c'est fichu, ils n'accepteront pas la méthode.

Je viens de passer la soirée à préparer une classe de gestion de fichier XML pour mes settings et tout fonctionne comme je le souhaite.

Merci de ton aide.
0
Rejoignez-nous