Discussion :

[Golard]

Bonjour à tous,

J'ai développé une application WPF codé en VB.Net

J'enregistre les paramètres que je souhaite recharger au lancement de l'application dans des fichiers que j'enregistre ici:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

My.Application.Info.DirectoryPath

Après installation de mon application My.Application.Info.DirectoryPath = "C:\Program Files (x86)\MonApplication\"

Tout va bien en développement, où sur mes postes où je suis administrateur.

MON PROBLEME: Si j'installe sur un poste simple utilisateur, le système refuse que l'application écrive dans "C:\Program Files (x86)\MonApplication\" ==> msg erreur système

D'où mes questions :

Dans que dossier me conseillez-vous d'enregistrer mes paramètres ?
Faut-il continuer d'utiliser My.Application.Info.DirectoryPath et dans ce cas existe-t'il un paramètre dans le projet setup (installshield) qui permet à un simple utilisateur à écrire dans Program Files (x86) ?

MERCI d'avance pour vos conseils

[r.morel]

Bonjour,
Je pense que ce serait intéressant d'utiliser le dossier Application Data qui est spécifique à chaque utilisateur.
Les droits nécessaires sont attribués automatiquement par windows.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData))

Plus d'infos : https://msdn.microsoft.com/fr-fr/lib...vs.110%29.aspx

Cordialement.

[Golard]

Merci r.morel pour cette piste.

En explorant les infos msdn, j'ai trouvé 3 dossiers qui semblent concerner les fichiers d'une appli:

• ApplicationData Répertoire servant de référentiel commun pour les données spécifiques à l'application qui sont utilisées par l'utilisateur itinérant actuel.
  Un utilisateur itinérant travaille sur plusieurs ordinateurs d'un même réseau. Son profil est stocké sur un serveur du réseau et est chargé sur le système lorsqu'il ouvre une session.
• LocalApplicationData Répertoire servant de référentiel commun pour les données spécifiques à l'application utilisées par l'utilisateur non itinérant actuel.
• CommonApplicationData Répertoire servant de référentiel commun pour les données spécifiques à l'application qui sont utilisées par tous les utilisateurs.

Malgré l'explication msdn, la notion d'utilisateur itinérant reste assez abstraite...

Je pense utiliser finalement les 2 répertoires suivants:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)

pour mon fichier paramètre concernant la clef de déverrouillage de l'appli==> ainsi l'appli sera bien déverrouillée pour TOUS les utilisateurs du poste (c'est ce que je veux).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)

pour mon fichier paramètre permettant de personnaliser l'interface ==> ainsi plusieurs utilisateurs du poste pourront avoir chacun leur propre personnalisation.

Cependant, j'hésite pour ce dernier avec ApplicationData, vu que je ne saisi pas la subtilité de la nuance !

Pouvez-vous me dire ce que vous en pensez ?

Me dire si ce choix vous semble correct ?

Merci !

[r.morel]

Je crois que le dossier Application Data sert aux paramètres "non exploitables" en sur une autre machine.
Voici des informations concernant W8 : http://windows.microsoft.com/fr-fr/w...appdata-folder
En espérant t'avoir aider.

[Golard]

Merci !

Je crois comprendre de cet article que:

• Le dossier Roaming (%appdata%) correspond à Environment.SpecialFolder.ApplicationData
• Le dossier Local (%localappdata%) correspond à Environment.SpecialFolder.LocalApplicationData

Mon application étant installée en local sur un poste (C:\Program Files (x86)\MonApplication\), je ne souhaite pas que les données qui puissent "accompagner un profil utilisateur de PC en PC", donc je laisse de coté le dossier Roaming.

Je pense donc utiliser

1. le dossier Local (Environment.SpecialFolder.LocalApplicationData) pour les paramètres utilisateurs de l'application (cela semble un standard puisque "la majorité des applications du Windows Store utilisent le dossier Local par défaut")
2. le dossier CommonApplicationData (Environment.SpecialFolder.CommonApplicationData) pour un petit fichier spécifique au déverrouillage de l'application sur le poste (et donc indépendant de l'utilisateur).

J'ai bon ?

[r.morel]

Je pense que oui.
Reste plus qu'a essayer...

Tiens nous informé.

[clementmarcotte]

Bonjour,

Bonjour à tous,

J'ai développé une application WPF codé en VB.Net

J'enregistre les paramètres que je souhaite recharger au lancement de l'application dans des fichiers que j'enregistre ici:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

My.Application.Info.DirectoryPath

MERCI d'avance pour vos conseils

Mais, si tu utilises My.settings (en lecture/écriture) et l'onglet "Paramètres" du MyProject, tes paramètres vont se retrouver automatiquement dans le app.config qui devrait en principe se retrouver automatiquement dans le dossier de l'application avec l'exécutable déployé.

Une fois que tu as défini un paramètre dans l'onglet paramètres, tu peux le rappeler et le modifier à volonté. Même que tu peux t'en servir pour enregistrer le contenu d'une Form "Options" que ton utilisateur peut modifier à loisir, en fonction de ses goûts et des ses besoins.

Pour enregistrer la (nouvelle) valeur du paramètre Zébulon.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

my.settings.zébulon =  32

Pour récupérer la valeur de zébulon dans une variable:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

dim largeur as integer = my.settings.zébulon

P.S le app.config est en fait un simple fichier xml que tu ouvrir dans le bloc-notes.

[r.morel]

Salut,
Je viens de vérifier sur mon application dans laquelle j'ai utilisé la solution "My.Settings" présenté ici par clementmarcotte.
Une fois installé le fichier xml est stocké dans le dossier : C:\Users\nom_utilisateur\AppData\Local\Nom_Suite\Nom_application\Version_assembly

Donc notre raisonnement semble cohérent.

[Pol63]

selon certains les my.settings sont à éviter (dont moi mais je ne sais plus pourquoi vu que je les ai abandonné il y a quelques années, m'enfin s'il y a la version de l'assembly dans le path c'est déjà un mauvais point dans certains cas)

[wallace1]

Bonjour à tous,

Je rejoins Pol63 sur l'utilisation de my.Settings, considères ce gros inconvénient dans le lien suivant :

http://www.developpez.net/forums/d14...s/#post7933735

Tu as également un sujet intéressant sur l'avantage et les inconvénients des méthodes d'enregistrement de paramètres d'application ici :

http://www.developpez.net/forums/d14...s/#post7933572

Bonne lecture.

A++

[Golard]

Merci à tous pour vos conseils !!!

Pour vous résumer mon opinion:

• BDR, j'ai déjà donné dans une grosse appli, ça marche mais je souhaitais être un peu plus indépendant de l'OS.
• BDD, si on parle bien de base de données, ça me semble un peu gros à mettre en place si l'appli n'a pas déjà de base !
• My.settings, ça m'avait l'air assez prometteur avant de lire vos notes... Maintenant que je sais que le dossier intègre un n° de version, c'est juste bon à jeter.
• INI ou XML, là on parle bien de fichiers gérables en tant que tel dans le code; j'ai un préférence pour le XML pour sa hiérarchisation des données, l'INI étant pour moi le prédécesseur voué à la disparition.

Personnellement, j'utilise un fichier BIN que j'obtiens en sérialisant les données désirées. Les données restent accessibles dans un éditeur de texte, même si c'est beaucoup moins lisible que dans un fichier XML.

Et maintenant la conclusion sur où stocker ces fichiers:

Mon 1er fichier contient des données de déverrouillage et je souhaite que l'appli soit déverrouillée pour le poste quelque soi l'utilisateur. J'ai donc choisi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)

Sur Seven, en y ajoutant un répertoire pour mon fichier, cela correspond à

C:\ProgramData\MonAppli\

Mon second fichier contient des données spécifiques à l'utilisateur. J'ai donc choisi

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData)

Sur Seven, en y ajoutant un répertoire pour mon fichier, cela correspond à

C:\Utilisateurs\Toto\AppData\Local\MonAppli\

Grâce à ce choix de dossier (en remplacement de C:\Program Files (x86)\MonAppli\), l'appli fonctionne à présent pour un administrateur tout comme pour un simple utilisateur

Par contre, j'ai remarqué que ça ne fonctionnait pas pour le compte "Invité" de Seven
A priori ça ne me dérange pas, mais j'espère que ça ne cache pas quelque chose...
L'erreur que j'obtiens avec le compte invité est:



Je clos malgré tout le sujet , ce qui ne vous empêche pas d'apporter des infos si vous avez une idée pour l'erreur du compte invité

Merci !