Paramètres.settings vs app.config dans l'application de bureau .NET

Question

Double Possible:
Quelle est la différence entre l'application.le fichier de configuration et XYZ.fichier de paramètres?

Je suis assez confus par l'apparente redondance de ces deux mécanismes dans Visual Studio pour stocker et gérer de bureau, les paramètres de l'application:

• Vous pouvez utiliser le XML app.config le fichier, ajouter des éléments à l' <appSettings> section. Ceux-ci peuvent être récupérées à partir du code à l'aide de l' ConfigurationManager classe.
• Alternativement, vous pouvez utiliser les Paramètres.fichier de paramètres pour ajouter des paramètres individuels par le biais d'un éditeur. Visual Studio génère un Settings classe de type-safe extraction de paramètres au moment de l'exécution.

Ces deux mécanismes semblent servir le même (ou à peu près les mêmes). Je suis au courant il y a quelques différences, mais je suis aussi intrigué par le chevauchement et de ses conséquences. Par exemple, lorsque j'utilise Visual Studio pour ajouter des paramètres à l' Settings.settings le fichier, toutes les informations que j'ai mis en finit entrées dans l' app.config le fichier. Apparemment, il existe un mécanisme de synchronisation: si je change un paramètre dans l' app.config le fichier, Visual Studio me demande de mettre à jour l' Settings.settings le fichier la prochaine fois, je l'ouvre dans l'éditeur.

Mes questions sont les suivantes:

• Pourquoi deux mécanismes et pas seulement un?
• Quels sont les scénarios les plus courants pour l'utilisation d' app.config sur Settings.settings, et vice-versa?
• Qu'advient-il si mon application est à l'aide de Settings.settings et j'ai modifier une valeur en app.config après avoir été déployé? Pas de synchronisation de l' Settings.settings peut arriver puisqu'il a déjà été établi et distribué.

Remarque. J'ai cherché pour les questions sur ce sujet, mais je suis encore plus confus. Par exemple, les réponses à cette question ici sont tout à fait contradictoires et ne pas jeter beaucoup de lumière.

Note 2. Je suis conscient qu' app.config est un moment de la conception de nom de fichier, et je suis familier avec la dynamique de Visual Studio copier et renommer le dossier exécutable.

Answer 1

Pourquoi deux mécanismes et pas seulement un?

Ils servent à des fins différentes. Les paramètres de l'API offre des accès en lecture/écriture à partir de l'application, alors que la config est en lecture seule (sauf si vous écrivez le fichier dans le code).

Les paramètres peuvent être définis par l'utilisateur ou par demande, et sont destinées à être volatils. Les paramètres de l'utilisateur sont écrits dans dossier caché de l'Utilisateur le Profil de stockage qui est autorisé en vertu de l'UAC.

App.la config est par l'application. Les changements d'App.config ne sont pas automatiquement pris. Il nécessite un redémarrage ou le code pour actualiser les valeurs. En vertu de l'UAC des utilisateurs ne sont pas autorisés à écrire dans les répertoires d'application tels que les Fichiers de Programme, ce fichier doit être considérée comme statique en lecture seule.

Quels sont les scénarios les plus courants pour l'utilisation d'app.config plus Les paramètres.paramètres, et vice-versa?

Vous pouvez utiliser les Paramètres dans une application de bureau pour stocker les préférences de l'utilisateur ou les paramètres qui sont modifiés lors de l'exécution.

Vous utilisez l'Application.config pour plus générique paramètres statiques, comme les chaînes de connexion, etc, ou pour définir la configuration des composants utilisés dans votre application.

Qu'advient-il si mon application est à l'aide de Paramètres.les paramètres et j'ai changer un valeur dans l'app.config après avoir été déployé?

Si la demande est redéployé, alors il sera de ramasser les nouveaux paramètres, sauf si il y a des utilisateur/application de personnalisation sur la machine, auquel cas, il va continuer à les utiliser, à moins que vous les essuyer.

Si vous ajoutez de nouveaux paramètres, ils seront ramassés. En fait, les valeurs par défaut sont cuits dans les Paramètres de la classe, de sorte que même si l'application.config est vide, les Paramètres de la fonction.

Answer 2

À partir d'un .NET Framework point de vue (il ne parle pas des outils Visual Studio pour le moment), historiquement, il n'y avait qu' [app.exe].config (en fait, c'est ce que le domaine d'application définit comme le fichier de configuration. Le nom est défini par le domaine d'application, c'est pourquoi il est web.config pour les applications web...) et machine.config. 'app' est déployé avec la demande, la "machine" est pour l'ensemble de la machine. Ils étaient censés être "très" en lecture seule pour l'utilisateur moyen. Il est possible de les changer, mais il n'était pas l'idée.

Mais comment puis-je enregistrer fin des préférences de l'utilisateur, alors? C'est pourquoi [l'utilisateur].config a été introduite (je crois avec .NET 2). La documentation officielle dit ceci:

Le système de configuration qui a été initialement publié avec le .NET Cadre soutient la fourniture d'application statique des données de configuration à travers la machine de l'ordinateur local.fichier de configuration ou dans un app.exe.fichier de configuration que vous déployez votre application. L' LocalFileSettingsProvider classe étend cette prise en charge native dans le une des manières suivantes:

1) portée Application réglages peuvent être mémorisés dans la machine.config ou de l'application.exe.les fichiers de configuration. De la Machine.la config est toujours en lecture seule, alors que app.exe.la config est limitée par des considérations de sécurité, en lecture seule pour la plupart des applications.

2) l'Utilisateur d'étendue de paramètres peuvent être stockés dans l'application.exe.les fichiers de configuration, dans lequel cas, ils sont traités comme statique par défaut.

3) Non-utilisateur par défaut-portée, les paramètres sont stockés dans un fichier, de l'utilisateur.config, où utilisateur est le nom d'utilisateur de la personne actuellement l'exécution de l'application. Vous pouvez spécifier une valeur par défaut pour un utilisateur dont l'étendue réglage avec DefaultSettingValueAttribute. Parce que l'utilisateur l'étendue du les paramètres changent souvent au cours de l'exécution de l'application, l'utilisateur.la config est toujours en lecture/écriture.

Donc, à partir de un .NET Framework point de vue, il y a une seule couche de 3-mécanisme.

Maintenant, Visual Studio essaie juste de vous aider en générant le code de type sécurisé pour la finale de la lecture/écriture des paramètres. La plupart du temps, que [utilisateur].fichier de configuration n'existe pas et la valeur d'un paramètre défini par ce qui est dans l' DefaultSettingValueAttribute (défini pour chaque paramètre), ou d'utiliser ce qui a été défini de façon statique dans l'application.config. C'est pourquoi Visual Studio met également à jour l'application.fichier de configuration de sorte que vous pouvez définir statique par défaut pour les paramètres. Mais vous pouvez parfaitement tout supprimer cette application.config choses.