appSettings vs applicationSettings. appSettings obsolète?

J’ai quelques questions sur deux manières de sauvegarder les parameters dans le fichier web.config.

Appsettings : Regardez dans web.config

    

Utilisation dans code-behind :

 ConfigurationManager.AppSettings["key1"]; 

ApplicationSettings / Properties (généré automatiquement à l’aide de l’onglet “properties” du projet)
Rechercher dans web.config

    True    

Utilisation dans code-behind :

 Properties.Settings.Default.TestEnvironment 

Alors, quelle est la différence entre ces deux possibilités de stockage de parameters dans le fichier web.config?
Autant que je sache, un des inconvénients des appSettings est que vous avez modifié le fichier web.config vous-même et que les parameters appSettings ne sont pas typescripts, alors que les parameters applicationSettings le sont.

Les deux sont remplaçables dans un projet de déploiement Web.

En ce qui me concerne, les appSettings ne sont pas utiles . Est-ce que j’ai râté quelque chose? Quel est le plus ancien historiquement vu?

Cela a déjà été discuté ici: Avantages et inconvénients de appSettings vs applicationSettings (.NET app.config) .

En ce qui concerne vos questions: la plus ancienne est >, elle existait avant la version 2.0, > est devenue disponible en 2.0.

Avantage? Lorsque je modifie une valeur ou que j'ajoute une valeur sur un serveur où le meilleur outil est notepad, > est très verbeux et parfois je veux juste une chaîne . Peut-être un exemple idiot, mais quand je modifie les parameters de configuration entre les niveaux pour obtenir la configuration du déploiement automatique, il est extrêmement utile que ce soit simple.

Je suis d'accord avec Marc_s de l'autre discussion, cependant, si vous faites quelque chose de vraiment complexe, vous approchez probablement du point où vous devriez avoir votre propre section de configuration. Puisque vous désérialisez dans votre type de configuration au démarrage ... vous obtenez le même type en vérifiant de cette manière, juste via le sérialiseur XML directement est la seule différence.

Cela a aussi l'avantage de faire Config.LDAPServer ou peut-être une config pour différentes zones, comme Security.Config et Themes.Config (deviner ici!), Vous pouvez obtenir un schéma de dénomination vraiment utile / clair en tant Themes.Config secondaire .

ApplicationSettings est un espace de noms, de sorte que deux assemblys différents peuvent avoir un paramètre de “timeout” sans conflit et que ApplicationSettings est facultatif puisque la valeur par défaut est définie via un atsortingbut sur le paramètre dans le code.

Une chose que j’ai remarquée est que les valeurs AppSettings peuvent être référencées via les balises inline <%$ AppSettings: name %> dans les pages aspx, mais il ne semble pas y avoir de moyen équivalent d’accéder aux valeurs ApplicationSettings via des balises inline.

Je voudrais append que l’interface graphique IIS 8.0 (et les versions précédentes également) ne peuvent pas éditer la section (elle est invisible, c’est-à-dire qu’elle apparaît comme si aucun paramètre ne peut être configuré) alors que est modifiable avec IIS 8.0.

Il aurait été intéressant que VS2012 / IIS 8.0 utilise le même système de configuration de l’interface graphique, mais les produits ne semblent pas être synchronisés dans cet aspect. D’une manière ou d’une autre, vous devrez peut-être modifier les parameters de l’application avec le Bloc-notes.

Les chaînes de connexion apparaissent dans les deux interfaces graphiques, mais si vous utilisez dans IIS, elles incluent le chemin d’access complet ( espace de noms .Properties.Settings. ConnectionSsortingngName ).