appSettings vs applicationSettings. appSettings obsolète?

Question

J'ai quelques questions à propos de deux façons d'enregistrer les paramètres dans le web.config.

Appsettings: Rechercher dans le web.config

<appSettings>
 <add key="key1" value="value1"/>
 <add key="key2" value="value2"/>
</appSettings>

L'utilisation dans le code-behind:

ConfigurationManager.AppSettings["key1"];

ApplicationSettings/ Propriétés (générée automatiquement en utilisant le "propriétés" -onglet dans le projet)
Rechercher dans le web.config

<applicationSettings>
    <Projectname.Properties.Settings>
        <setting name="TestEnvironment" serializeAs="String">
            <value>True</value>
        </setting>
    </Projectname.Properties.Settings>
</applicationSettings>

L'utilisation dans le code-behind:

Properties.Settings.Default.TestEnvironment

Alors, quelle est la différence entre ces deux possibilités de stockage de paramètres dans le web.config?
Aussi loin que je peux voir, une baisse de la appSettings est que vous avez modifier le site web.config soi-même et le appSettings ne sont pas fort typé, où, comme le applicationSettings sont.

Les deux sont remplaçables à l'intérieur d'un projet de déploiement web.

Pour autant que je suis concerné, il n'y a pas d'utilisation d'appSettings. Suis-je manqué quelque chose? Ce qui est toujours un plus âgé?

Answer 1

Cela a été discuté avant ici: les avantages et les inconvénients de appSettings vs applicationSettings (.NET application.config).

Comme pour répondre à vos questions: Le plus ancien est - <appSettings>, il a été autour avant 2.0, <applicationSettings> sont disponibles en 2.0.

Avantage? Quand je suis en train de modifier une valeur, ou l'ajout d'une valeur sur un serveur où le meilleur outil est le bloc-notes <applicationSettings> est très bavard, et parfois, je veux juste une chaîne de caractères. Peut-être un idiot exemple, mais quand je suis à peaufiner les paramètres de configuration entre les niveaux pour obtenir le déploiement automatique de l'installation correctement, il est extrêmement utile que c'est simple.

Je suis d'accord avec marc_s de l'autre discussion, si vous faites quelque chose qui est vraiment complexe, vous êtes probablement en train d'atteindre le point, vous devriez avoir votre propre section de configuration de toute façon. Puisque vous êtes de sérialisation dans votre config type de démarrage...vous obtenez le même type de vérification, via le Sérialiseur XML directement est la seule différence.

Cela a aussi l'avantage de me faire Config.LDAPServer ou peut-être une config pour les différentes zones, chacune, comme Security.Config et Themes.Config (deviner ici!), vous pouvez obtenir un très utile/clair schéma de nommage là aussi un autre avantage.

Answer 2

ApplicationSettings sont des noms d'espacement, de sorte que deux assemblys différents peuvent avoir un paramètre de "délai d'attente" sans conflit, et ApplicationSettings sont facultatifs, car la valeur par défaut est définie via un attribut du paramètre dans le code.

Answer 3

J'ai remarqué que les valeurs AppSettings peuvent être référencées via des balises inline <%$ AppSettings: name %> dans des pages aspx, mais il ne semble exister aucun moyen équivalent d'accéder aux valeurs ApplicationSettings via des balises inline.

Answer 4

Je voudrais ajouter que IIS 8.0 GUI (et versions antérieures) ne peut pas modifier l' <applicationSettings> section (il est invisible, c'est à dire qu'il apparaît comme si aucun paramètre peut être configuré) alors qu' <appSettings> sont modifiables avec IIS 8.0.

Il aurait été agréable si VS2012/IIS 8.0 utilisé le même GUI configurer le système tout le chemin, mais les produits ne semblent pas être synchronisées dans cet aspect. D'une façon ou l'autre, vous pouvez avoir à modifier les paramètres de l'application avec le bloc-notes.

Les chaînes de connexion apparaissent dans les deux des Interfaces utilisateur graphiques, mais si vous utilisez <applicationSettings> dans IIS ils comprennent chemin d'accès complet (espace de Noms.Les propriétés.Les paramètres.ConnectionStringName).