Partager via

Architecture des paramètres d’application

Cette rubrique décrit le fonctionnement de l’architecture des paramètres d’application et explore les fonctionnalités avancées de l’architecture, telles que les paramètres groupés et les clés de paramètres.

L’architecture des paramètres de l'application prend en charge la définition de paramètres à typage strict avec une portée d'application ou d'utilisateur et la conservation des paramètres entre les sessions de l'application. L’architecture fournit un moteur de persistance par défaut pour enregistrer les paramètres et les charger à partir du système de fichiers local. L’architecture définit également des interfaces pour fournir un moteur de persistance personnalisé.

Les interfaces sont fournies pour permettre aux composants personnalisés de conserver leurs propres paramètres lorsqu’ils sont hébergés dans une application. En utilisant des clés de paramètres, les composants peuvent conserver les paramètres de plusieurs instances du composant séparément.

Définition des paramètres

L’architecture des paramètres d’application est utilisée à la fois dans ASP.NET et Windows Forms, et contient un certain nombre de classes de base partagées entre les deux environnements. Le plus important est SettingsBase, qui fournit l’accès aux paramètres via une collection et fournit des méthodes de bas niveau pour le chargement et l’enregistrement des paramètres. Chaque environnement implémente sa propre classe dérivée SettingsBase pour fournir des fonctionnalités de paramètres supplémentaires pour cet environnement. Dans une application Windows Forms, tous les paramètres d’application doivent être définis sur une classe dérivée de la ApplicationSettingsBase classe, ce qui ajoute les fonctionnalités suivantes à la classe de base :

  • Processus de chargement et d’enregistrement de haut niveau

  • Prise en charge des paramètres délimités par l’utilisateur

  • Restauration des paramètres d’un utilisateur aux valeurs par défaut prédéfinies

  • Mise à niveau des paramètres à partir d’une version précédente de l’application

  • Validation des paramètres avant leur modification ou avant leur enregistrement

Les paramètres peuvent être décrits à l’aide d’un certain nombre d’attributs définis dans l’espace System.Configuration de noms ; ceux-ci sont décrits dans Attributs des paramètres d’application. Lorsque vous définissez un paramètre, vous devez l’appliquer avec ApplicationScopedSettingAttribute ou UserScopedSettingAttribute, ce qui indique si le paramètre s’applique à l’ensemble de l’application ou simplement à l’utilisateur actuel.

L’exemple de code suivant définit une classe de paramètres personnalisée avec un seul paramètre. BackgroundColor

using System;
using System.Configuration;
using System.Drawing;

public class MyUserSettings : ApplicationSettingsBase
{
    [UserScopedSetting()]
    [DefaultSettingValue("white")]
    public Color BackgroundColor
    {
        get
        {
            return ((Color)this["BackgroundColor"]);
        }
        set
        {
            this["BackgroundColor"] = (Color)value;
        }
    }
}

Imports System.Configuration

Public Class MyUserSettings
    Inherits ApplicationSettingsBase
    <UserScopedSetting()> _
    <DefaultSettingValue("white")> _
    Public Property BackgroundColor() As Color
        Get
            BackgroundColor = Me("BackgroundColor")
        End Get

        Set(ByVal value As Color)
            Me("BackgroundColor") = value
        End Set
    End Property
End Class

Persistance des paramètres

La ApplicationSettingsBase classe ne se conserve pas ou ne charge pas les paramètres ; ce travail appartient au fournisseur de paramètres, une classe qui dérive de SettingsProvider. Si une classe dérivée de ApplicationSettingsBase ne spécifie pas de fournisseur de paramètres par le SettingsProviderAttribute, alors le fournisseur par défaut, LocalFileSettingsProvider, est utilisé.

Le système de configuration qui a été publié à l’origine avec .NET Framework prend en charge la fourniture de données de configuration d’application statiques via le fichier machine.config de l’ordinateur local ou dans un app. fichierexe.config que vous déployez avec votre application. La LocalFileSettingsProvider classe développe cette prise en charge native de la manière suivante :

  • Les paramètres d’étendue de l’application peuvent être stockés dans les fichiers machine.config ou app.exe.config. Machine.config est toujours en lecture seule, tandis que app.exe.config est rendu en lecture seule pour la plupart des applications en raison de considérations de sécurité.

  • Les paramètres définis par l’utilisateur peuvent être stockés dans app des fichiers.exe.config, auquel cas ils sont traités comme des valeurs par défaut statiques.

  • Les paramètres non définis par l’utilisateur par défaut sont stockés dans un nouveau fichier, user.config. Vous pouvez spécifier une valeur par défaut pour un paramètre défini par l’utilisateur avec DefaultSettingValueAttribute. Étant donné que les paramètres définis par l’utilisateur changent souvent pendant l’exécution de l’application, user.config est toujours en lecture/écriture. Pour plus d’informations, consultez Où sont stockés les paramètres délimités par l’utilisateur.

Les trois fichiers de configuration stockent les paramètres au format XML. L’élément XML de niveau supérieur pour les paramètres d’étendue de l’application est <appSettings>, tandis que <userSettings> est utilisé pour les paramètres définis par l’utilisateur. Un app fichier.exe.config qui contient à la fois les paramètres à l'échelle de l'application et les paramètres par défaut pour les paramètres utilisateur ressemble à ceci :

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="WindowsApplication1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
        </sectionGroup>
        <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="WindowsApplication1.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" />
        </sectionGroup>
    </configSections>
    <applicationSettings>
        <WindowsApplication1.Properties.Settings>
            <setting name="Cursor" serializeAs="String">
                <value>Default</value>
            </setting>
            <setting name="DoubleBuffering" serializeAs="String">
                <value>False</value>
            </setting>
        </WindowsApplication1.Properties.Settings>
    </applicationSettings>
    <userSettings>
        <WindowsApplication1.Properties.Settings>
            <setting name="FormTitle" serializeAs="String">
                <value>Form1</value>
            </setting>
            <setting name="FormSize" serializeAs="String">
                <value>595, 536</value>
            </setting>
        </WindowsApplication1.Properties.Settings>
    </userSettings>
</configuration>

Pour obtenir une définition des éléments dans la section paramètres de l’application d’un fichier de configuration, consultez Schéma des paramètres d’application.

Liaisons de paramètres

Les paramètres d’application utilisent l’architecture de liaison de données Windows Forms pour fournir une communication bidirectionnelle des mises à jour des paramètres entre l’objet de paramètres et les composants. Si vous utilisez Visual Studio pour créer des paramètres d’application et les affecter aux propriétés du composant, ces liaisons sont générées automatiquement.

Vous ne pouvez lier un paramètre d’application qu’à un composant prenant en charge l’interface IBindableComponent . En outre, le composant doit implémenter un événement de modification pour une propriété liée spécifique ou notifier les paramètres de l’application que la propriété a changé via l’interface INotifyPropertyChanged . Si le composant n’implémente IBindableComponent pas et que vous effectuez une liaison via Visual Studio, les propriétés liées seront définies la première fois, mais ne seront pas mises à jour. Si le composant implémente IBindableComponent mais ne prend pas en charge les notifications de changement de propriété, la liaison ne sera pas mise à jour dans le fichier de configuration lorsque la propriété est modifiée.

Certains composants Windows Forms, tels que ToolStripItem, ne prennent pas en charge les liaisons de paramètres.

Sérialisation des paramètres

Quand LocalFileSettingsProvider vous devez enregistrer les paramètres sur le disque, il effectue les actions suivantes :

  1. Utilise la réflexion pour examiner toutes les propriétés définies sur votre ApplicationSettingsBase classe dérivée, en recherchant celles qui sont appliquées avec l’une ou l’autre ApplicationScopedSettingAttributeUserScopedSettingAttribute.

  2. Sérialise la propriété sur le disque. Il tente d’abord d’appeler le ConvertToString ou ConvertFromString sur le type associé TypeConverter. Si cela ne réussit pas, il utilise la sérialisation XML à la place.

  3. Détermine les paramètres dans lesquels se trouve les fichiers, en fonction de l’attribut du paramètre.

Si vous implémentez votre propre classe de paramètres, vous pouvez utiliser le SettingsSerializeAsAttribute paramètre pour marquer un paramètre pour la sérialisation binaire ou personnalisée à l’aide de l’énumération SettingsSerializeAs . Pour plus d’informations sur la création de votre propre classe de paramètres dans le code, consultez Guide pratique pour créer des paramètres d’application.

Emplacements des fichiers de paramètres

L’emplacement des fichiers app.exe.config et utilisateur.config diffèrera en fonction de la façon dont l’application est installée. Pour une application Windows Forms copiée sur l’ordinateur local, app.exe.config résidera dans le même répertoire que le répertoire de base du fichier exécutable principal de l’application, et l’utilisateur.config résidera à l’emplacement spécifié par la Application.LocalUserAppDataPath propriété. Pour une application installée par le biais de ClickOnce, ces deux fichiers se trouvent dans le répertoire de données ClickOnce sous %InstallRoot%\Documents et Paramètres\username\Local Settings.

L’emplacement de stockage de ces fichiers est légèrement différent si un utilisateur a activé des profils itinérants, ce qui permet à un utilisateur de définir différents paramètres Windows et d’application lorsqu’il utilise d’autres ordinateurs au sein d’un domaine. Dans ce cas, les applications ClickOnce et les applications non-ClickOnce ont leurs app.exe.config et leurs fichiers d'.config utilisateur stockés sous %InstallRoot%\Documents et Paramètres\username\Application Data.

Pour plus d’informations sur le fonctionnement de la fonctionnalité Paramètres d’application avec la nouvelle technologie de déploiement, consultez ClickOnce et Paramètres d’application. Pour plus d’informations sur le répertoire de données ClickOnce, consultez Accès aux données locales et distantes dans les applications ClickOnce.

Paramètres et sécurité de l’application

Les paramètres d’application sont conçus pour fonctionner en confiance partielle, un environnement restreint qui est la valeur par défaut pour les applications Windows Forms hébergées sur Internet ou un intranet. Aucune autorisation spéciale au-delà de la confiance partielle n’est nécessaire pour utiliser les paramètres d’application avec le fournisseur de paramètres par défaut.

Lorsque les paramètres d’application sont utilisés dans une application ClickOnce, le user fichier.config est stocké dans le répertoire de données ClickOnce. La taille du fichier user.config de l’application ne peut pas dépasser le quota du répertoire de données défini par ClickOnce. Pour plus d’informations, consultez ClickOnce et Paramètres d’application.

Fournisseurs de paramètres personnalisés

Dans l’architecture des paramètres d’application, il existe un couplage libre entre la classe wrapper des paramètres des applications, dérivée de ApplicationSettingsBase, et le fournisseur de paramètres ou les fournisseurs associés, dérivés de SettingsProvider. Cette association est définie uniquement par l’application SettingsProviderAttribute à la classe wrapper ou à ses propriétés individuelles. Si un fournisseur de paramètres n’est pas spécifié explicitement, le fournisseur par défaut, LocalFileSettingsProviderest utilisé. Par conséquent, cette architecture prend en charge la création et l’utilisation de fournisseurs de paramètres personnalisés.

Par exemple, supposons que vous souhaitez développer et utiliser SqlSettingsProvider, un fournisseur qui stocke toutes les données de paramètres dans une base de données Microsoft SQL Server. Votre SettingsProviderclasse dérivée reçoit ces informations dans sa Initialize méthode en tant que paramètre de type System.Collections.Specialized.NameValueCollection. Vous allez ensuite implémenter la GetPropertyValues méthode pour récupérer vos paramètres à partir du magasin de données et SetPropertyValues les enregistrer. Votre fournisseur peut utiliser le SettingsPropertyCollection fourni à GetPropertyValues pour déterminer le nom, le type et la portée de la propriété, ainsi que les autres attributs de configuration définis pour cette propriété.

Votre fournisseur doit implémenter une propriété et une méthode dont les implémentations peuvent ne pas être évidentes. La ApplicationName propriété est une propriété abstraite de SettingsProvider; vous devez la programmer pour retourner les éléments suivants :

public override string ApplicationName
{
    get
    {
        return (System.Reflection.Assembly.GetExecutingAssembly().GetName().Name);
    }
    set
    {
        // Do nothing.
    }
}

Public Overrides Property ApplicationName() As String
    Get
        ApplicationName = System.Reflection.Assembly.GetExecutingAssembly().GetName().Name
    End Get
    Set(ByVal value As String)
        ' Do nothing.
    End Set
End Property

Votre classe dérivée doit également implémenter une Initialize méthode qui ne prend aucun argument et ne retourne aucune valeur. Cette méthode n’est pas définie par SettingsProvider.

Enfin, vous implémentez IApplicationSettingsProvider sur votre fournisseur pour prendre en charge l’actualisation des paramètres, rétablir les paramètres par défaut et mettre à niveau les paramètres d’une version d’une application vers une autre.

Une fois que vous avez implémenté et compilé votre fournisseur, vous devez indiquer à votre classe de paramètres d’utiliser ce fournisseur au lieu de la valeur par défaut. Vous effectuez cela par le biais du SettingsProviderAttribute. S’il est appliqué à une classe de paramètres entière, le fournisseur est utilisé pour chaque paramètre défini par la classe ; si elle est appliquée à des paramètres individuels, l’architecture Des paramètres d’application utilise ce fournisseur uniquement pour ces paramètres et les utilise LocalFileSettingsProvider pour le reste. L’exemple de code suivant montre comment indiquer à la classe de paramètres d’utiliser votre fournisseur personnalisé.

using System;
using System.Collections.Generic;
using System.Text;
using System.Configuration;

namespace ApplicationSettingsArchitectureCS
{
    [SettingsProvider("SqlSettingsProvider")]
    class CustomSettings : ApplicationSettingsBase
    {
        // Implementation goes here.
    }
}

Imports System.Configuration

<SettingsProvider("SqlSettingsProvider")> _
Public Class CustomSettings
    Inherits ApplicationSettingsBase

    ' Implementation goes here.
End Class

Un fournisseur peut être appelé simultanément à partir de plusieurs threads, mais il écrit toujours dans le même emplacement de stockage ; par conséquent, l’architecture des paramètres d’application n’instancie qu’une seule instance de votre classe de fournisseur.

Important

Vous devez vous assurer que votre fournisseur est thread-safe et autorise un seul thread à la fois à écrire dans les fichiers de configuration.

Votre fournisseur n’a pas besoin de prendre en charge tous les attributs de paramètres définis dans l’espace System.Configuration de noms, bien qu'il doive au minimum prendre en charge ApplicationScopedSettingAttribute et UserScopedSettingAttribute, et devrait également prendre en charge DefaultSettingValueAttribute. Pour les attributs qu’il ne prend pas en charge, votre fournisseur doit simplement échouer sans générer de notification ; il ne doit pas lever d’exception. Si la classe de paramètres utilise une combinaison non valide d’attributs, toutefois — comme appliquer ApplicationScopedSettingAttribute et UserScopedSettingAttribute au même paramètre — votre fournisseur doit lever une exception et cesser son fonctionnement.

Voir aussi