web-dev-qa-db-fra.com

appSettings vs applicationSettings. appSettings obsolète?

J'ai des questions sur deux façons d'enregistrer les paramètres dans le web.config.

Réglages des applications : Regardez dans web.config

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

tilisation en code-behind:

ConfigurationManager.AppSettings["key1"];

ApplicationSettings/Properties (généré automatiquement en utilisant l'onglet 'propriétés' dans le projet)
Regardez dans web.config

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

tilisation en code-behind:

Properties.Settings.Default.TestEnvironment

Alors, quelle est la différence entre ces deux possibilités de stockage des paramètres dans le web.config?
.

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

En ce qui me concerne, il y a pas d'utilisation pour appSettings. Est-ce que j'ai râté quelque chose? Quel est le plus ancien vu historiquement?

c#asp.netpropertiesappsettingsweb-deployment-project
53
citronas

Ceci a été discuté avant ici: Avantages et inconvénients de appSettings vs applicationSettings (.NET app.config) .

Quant à vos questions: la plus ancienne est <appSettings>, c'était avant 2.0, <applicationSettings> est devenu disponible en 2.0.

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

Je dois être 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 de toute façon. Puisque vous désérialisez dans votre type de configuration au démarrage ... vous obtenez le même type de vérification de cette façon, juste via le sérialiseur XML directement est la seule différence.

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

22
Nick Craver

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

22
Bernhard Hofmann

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

6
Loophole

Je voudrais ajouter que IIS 8.0 GUI (et les versions précédentes également) ne peut pas modifier le <applicationSettings> section (elle est invisible, c'est-à-dire qu'elle apparaît comme si aucun paramètre ne peut être configuré) tandis que <appSettings> sont modifiables avec IIS 8.0.

Cela aurait été bien si VS2012/IIS 8.0 utilisait le même système de configuration GUI complètement, mais les produits ne semblent pas être synchronisés sous cet aspect. D'une manière ou d'une autre, vous devrez peut-être modifier les paramètres de l'application avec le bloc-notes.

Les chaînes de connexion apparaissent dans les deux interfaces graphiques, mais si vous utilisez <applicationSettings> dans IIS ils incluent le chemin complet (namespace. Properties.Settings .ConnectionStringName).

3
galmok