Ce que je veux réaliser est très simple: j'ai une application Windows Forms (.NET 3.5) qui utilise un chemin pour lire les informations. Ce chemin peut être modifié par l'utilisateur, en utilisant le formulaire d'options que je fournis.
Maintenant, je veux enregistrer la valeur du chemin d'accès dans un fichier pour une utilisation ultérieure. Ce serait l'un des nombreux paramètres enregistrés dans ce fichier. Ce fichier se trouverait directement dans le dossier de l'application.
Je comprends que trois options sont disponibles:
- Fichier ConfigurationSettings (appname.exe.config)
- Enregistrement
- Fichier XML personnalisé
J'ai lu que le fichier de configuration .NET n'est pas prévu pour y sauvegarder des valeurs. Quant au registre, je voudrais m'en éloigner le plus possible.
Est-ce à dire que je dois utiliser un fichier XML personnalisé pour enregistrer les paramètres de configuration?
Si c'est le cas, je voudrais voir un exemple de code (C #).
J'ai vu d'autres discussions sur ce sujet, mais ce n'est toujours pas clair pour moi.
Réponses:
Si vous travaillez avec Visual Studio, il est assez facile d'obtenir des paramètres persistants. Cliquez avec le bouton droit sur le projet dans l'Explorateur de solutions et choisissez Propriétés. Sélectionnez l'onglet Paramètres et cliquez sur l'hyperlien si les paramètres n'existent pas.
Utilisez l'onglet Paramètres pour créer des paramètres d'application. Visual Studio crée les fichiers
Settings.settings
etSettings.Designer.settings
qui contiennent la classe singletonSettings
héritée d' ApplicationSettingsBase . Vous pouvez accéder à cette classe à partir de votre code pour lire / écrire les paramètres de l'application:Cette technique est applicable à la fois pour la console, les Windows Forms et d'autres types de projets.
Notez que vous devez définir la propriété d' étendue de vos paramètres. Si vous sélectionnez Portée d'application, Settings.Default. <Votre propriété> sera en lecture seule.
Référence: Comment: écrire des paramètres utilisateur lors de l'exécution avec C # - Microsoft Docs
la source
Settings.Default.SomeProperty = 'value'; Settings.Default.Save();
fonctionne comme un charme. Ou est-ce parce que j'ai des paramètres utilisateur?Settings.Default.Save()
ne fait rien est incorrecte. Comme @aku l'indique dans la réponse, les paramètres de portée d'application sont en lecture seule: la sauvegarde est inefficace pour eux. Utilisez ce PortableSettingsProvider personnalisé pour enregistrer les paramètres de portée utilisateur dans le fichier app.config situé à l'emplacement de l'exe au lieu de celui du dossier AppData de l'utilisateur. Non, pas généralement bon, mais je l'utilise pendant le développement pour utiliser les mêmes paramètres de compilation en compilation (sans cela, ils vont de nouveaux dossiers utilisateur uniques avec chaque compilation).Si vous prévoyez d'enregistrer dans un fichier dans le même répertoire que votre exécutable, voici une bonne solution qui utilise le format JSON :
la source
DEFAULT_FILENAME
, il suffit d'appelersettings.Save(theFileToSaveTo)
; Être tout en majusculesDEFAULT_FILENAME
est censé être une constante . Si vous voulez une propriété en lecture-écriture, créez-en une et demandez au constructeur de la définir surDEFAULT_FILENAME
. Ensuite, définissez la valeur d'argument par défautnull
, testez-la et utilisez votre propriété comme valeur par défaut. C'est un peu plus de frappe, mais vous donne une interface plus standard.System.Web.Extensions.dll
si vous ne l'avez pas déjà fait.Le registre est un no-go. Vous n'êtes pas sûr que l'utilisateur qui utilise votre application dispose des droits suffisants pour écrire dans le registre.
Vous pouvez utiliser le
app.config
fichier pour enregistrer les paramètres au niveau de l'application (qui sont les mêmes pour chaque utilisateur qui utilise votre application).Je stockerais les paramètres spécifiques à l'utilisateur dans un fichier XML, qui serait enregistré dans le stockage isolé ou dans le répertoire SpecialFolder.ApplicationData .
À côté de cela, à partir de .NET 2.0, il est possible de stocker des valeurs dans le
app.config
fichier.la source
La
ApplicationSettings
classe ne prend pas en charge l'enregistrement des paramètres dans le fichier app.config . C'est très bien par conception; les applications qui s'exécutent avec un compte d'utilisateur correctement sécurisé (pensez à Vista UAC) n'ont pas accès en écriture au dossier d'installation du programme.Vous pouvez combattre le système avec la
ConfigurationManager
classe. Mais la solution de contournement triviale consiste à entrer dans le concepteur de paramètres et à modifier la portée du paramètre en utilisateur. Si cela cause des difficultés (par exemple, le paramètre est pertinent pour chaque utilisateur), vous devez placer votre fonctionnalité Options dans un programme distinct afin de pouvoir demander l'invite d'élévation des privilèges. Ou renoncez à utiliser un paramètre.la source
L'argument Registry / configurationSettings / XML semble toujours très actif. Je les ai tous utilisés, au fur et à mesure que la technologie a progressé, mais mon préféré est basé sur le système de Threed combiné avec le stockage isolé .
L'exemple suivant permet le stockage d'un objet nommé propriétés dans un fichier dans un stockage isolé. Tel que:
Les propriétés peuvent être récupérées en utilisant:
Il ne s'agit que d'un échantillon, ne suggérant pas les meilleures pratiques.
la source
Je voulais partager une bibliothèque que j'ai construite pour cela. C'est une petite bibliothèque, mais une grande amélioration (à mon humble avis) par rapport aux fichiers .settings.
La bibliothèque s'appelle Jot (GitHub) . Voici un vieil article de The Code Project que j'ai écrit à ce sujet.
Voici comment l'utiliser pour garder une trace de la taille et de l'emplacement d'une fenêtre:
L'avantage par rapport aux fichiers .settings: il y a beaucoup moins de code et il est beaucoup moins sujet aux erreurs car vous n'avez besoin de mentionner chaque propriété qu'une seule fois .
Avec un fichier de paramètres, vous devez mentionner chaque propriété cinq fois: une fois lorsque vous créez explicitement la propriété et quatre fois supplémentaires dans le code qui copie les valeurs d'avant en arrière.
Le stockage, la sérialisation, etc. sont entièrement configurables. Lorsque les objets cibles sont créés par un IoC conteneur , vous pouvez [le raccorder] [] afin qu'il applique automatiquement le suivi à tous les objets qu'il résout, de sorte que tout ce que vous devez faire pour rendre une propriété persistante est de gifler un [Trackable] attribuer dessus.
Il est hautement configurable et vous pouvez configurer: - lorsque les données sont persistantes et appliquées globalement ou pour chaque objet suivi - comment elles sont sérialisées - où elles sont stockées (par exemple fichier, base de données, en ligne, stockage isolé, registre) - règles qui peuvent annuler l'application / données persistantes pour une propriété
Croyez-moi, la bibliothèque est de premier ordre!
la source
Un moyen simple consiste à utiliser un objet de données de configuration, à l'enregistrer en tant que fichier XML avec le nom de l'application dans le dossier local et au démarrage à le relire.
Voici un exemple pour stocker la position et la taille d'un formulaire.
L'objet de données de configuration est fortement typé et facile à utiliser:
Une classe gestionnaire pour la sauvegarde et le chargement:
Vous pouvez maintenant créer une instance et l'utiliser dans les événements de chargement et de fermeture de votre formulaire:
Et le fichier XML produit est également lisible:
la source
c:\program files\my application
dossier, donc la sauvegarde des paramètres génère une erreur. Je cherche plutôt à enregistrer le fichier xml dans AppData, mais je me demandais simplement s'il y avait un moyen évident de contourner ce problème, car cette approche semble avoir fonctionné pour vous.Je n'aime pas la solution proposée d'utiliser
web.config
ouapp.config
. Essayez de lire votre propre XML. Jetez un œil aux fichiers de paramètres XML - Plus de web.config .la source
D'autres options, au lieu d'utiliser un fichier XML personnalisé, nous pouvons utiliser un format de fichier plus convivial: fichier JSON ou YAML.
Vous pouvez stocker votre fichier de paramètres dans plusieurs dossiers spéciaux (pour tous les utilisateurs et par utilisateur) comme indiqué ici Environment.SpecialFolder Enumeration et plusieurs fichiers (par défaut en lecture seule, par rôle, par utilisateur, etc.)
Si vous choisissez d'utiliser plusieurs paramètres, vous pouvez fusionner ces paramètres: par exemple, fusionner les paramètres par défaut + BasicUser + AdminUser. Vous pouvez utiliser vos propres règles: la dernière remplace la valeur, etc.
la source
"Cela signifie-t-il que je devrais utiliser un fichier XML personnalisé pour enregistrer les paramètres de configuration?" Non pas forcément. Nous utilisons SharpConfig pour de telles opérations.
Par exemple, si un fichier de configuration est comme ça
Nous pouvons récupérer des valeurs comme celle-ci
Il est compatible avec .NET 2.0 et supérieur. Nous pouvons créer des fichiers de configuration à la volée et nous pouvons les enregistrer plus tard.
Source: http://sharpconfig.net/
GitHub: https://github.com/cemdervis/SharpConfig
la source
Pour autant que je sache, .NET prend en charge les paramètres persistants à l'aide de la fonction de paramètres d'application intégrée:
la source
Parfois, vous voulez vous débarrasser de ces paramètres conservés dans le fichier web.config ou app.config traditionnel. Vous voulez un contrôle plus fin sur le déploiement de vos entrées de paramètres et la conception de données séparées. Ou l'exigence est d'activer l'ajout de nouvelles entrées lors de l'exécution.
Je peux imaginer deux bonnes options:
L'avantage de la version fortement typée réside dans les noms et valeurs des paramètres fortement typés. Il n'y a aucun risque de mélanger des noms ou des types de données. L'inconvénient est que plus de paramètres doivent être codés, ne peuvent pas être ajoutés au moment de l'exécution.
Avec la version orientée objet, l'avantage est que de nouveaux paramètres peuvent être ajoutés au moment de l'exécution. Mais vous n'avez pas de noms et de valeurs fortement saisis. Doit être prudent avec les identificateurs de chaîne. Doit connaître le type de données enregistré précédemment lors de l'obtention d'une valeur.
Vous pouvez trouver le code des deux implémentations entièrement fonctionnelles ICI .
la source
Oui, il est possible d'enregistrer la configuration - mais cela dépend à peu près de la façon dont vous choisissez de le faire. Permettez-moi de décrire les différences techniques afin que vous puissiez comprendre les options dont vous disposez:
Tout d'abord, vous devez distinguer si vous souhaitez utiliser applicationSettings ou AppSettings dans votre fichier
*.exe.config
(akaApp.config
dans Visual Studio) - il existe des différences fondamentales, décrites ici .Les deux offrent différentes façons d'enregistrer les modifications:
config.Save(ConfigurationSaveMode.Modified);
, où config est défini commeconfig = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
).Properties.Settings.Default.Save();
), elles seront écrites par utilisateur, stockées dans un endroit spécial (par exempleC:\Documents and Settings\USERID\Local Settings\Application Data\FIRMNAME\WindowsFormsTestApplicati_Url_tdq2oylz33rzq00sxhvxucu5edw2oghw\1.0.0.0
). Comme Hans Passant l'a mentionné dans sa réponse, cela est dû au fait qu'un utilisateur a généralement des droits restreints sur Program Files et ne peut pas y écrire sans invoquer l'invite UAC. Un inconvénient est que si vous ajoutez des clés de configuration à l'avenir, vous devez les synchroniser avec chaque profil utilisateur.Remarque: Comme mentionné dans la question, il existe une troisième option: si vous traitez le fichier de configuration comme un document XML, vous pouvez le charger, le modifier et l'enregistrer en utilisant la
System.Xml.Linq.XDocument
classe. Il n'est pas nécessaire d'utiliser un fichier XML personnalisé, vous pouvez lire le fichier de configuration existant; pour interroger des éléments, vous pouvez même utiliser des requêtes Linq. J'ai donné un exemple ici , consultez la fonctionGetApplicationSetting
là-bas dans la réponse.Si vous avez besoin d'un chiffrement pour protéger vos valeurs, consultez cette réponse.
la source
la source