Architecture des paramètres d'application

Article
06/02/2023

Cette rubrique décrit le fonctionnement de l’architecture Paramètres d’application et explore des 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 d’application prend en charge la définition des paramètres fortement typés avec l’application ou la portée utilisateur, et la persistance des paramètres entre les sessions d’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 les interfaces qui fournissent un moteur de persistance personnalisé.

Des interfaces sont fournies afin de permettre aux composants personnalisés de conserver leurs propres paramètres lorsqu’ils sont hébergés dans une application. À l’aide de clés de paramètres, les composants peuvent séparer les paramètres pour plusieurs instances du composant.

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 :

Chargement et enregistrement d’opérations de plus haut niveau
Prise en charge des paramètres de portée utilisateur
Rétablissement des paramètres d’un utilisateur aux valeurs par défaut
Mise à niveau des paramètres à partir d’une version précédente de l’application
Validation des paramètres, avant leur modification ou 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 Application Paramètres Attributs. Lorsque vous définissez un paramètre, vous devez l’appliquer avec ApplicationScopedSettingAttribute l’un ou l’autre des UserScopedSettingAttributeparamètres, 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és avec un paramètre unique, 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 biais du SettingsProviderAttributefournisseur , le fournisseur par défaut, LocalFileSettingsProviderest 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.fichier exe.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 de portée d’application peuvent être stockés dans des fichiers machine.config ou app.exe.config. Machine.config est toujours en lecture seule, tandis que app.exe.config est limité par des considérations de sécurité en lecture seule pour la plupart des applications.
Les paramètres de portée utilisateur peuvent être stockés dans des fichiers app.exe.config, fichiers, auquel cas ils sont traités comme des valeurs par défaut statiques.
Les paramètres non définis par défaut par l’utilisateur 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.

Ces trois fichiers de configuration stockent les paramètres au format XML. L’élément XML de niveau supérieur pour les paramètres de portée d’application est <appSettings>, tandis que <userSettings> est utilisé pour les paramètres de portée utilisateur. Un fichier app.exe.config contenant les paramètres de portée d’application et les valeurs par défaut pour les paramètres de portée utilisateur ressemblerait à 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 une définition des éléments dans la section Paramètres d’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 pour les mises à jour des paramètres entre les composants et l’objet de paramètres. 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 mais ne prend pas en charge les IBindableComponent notifications de modification de propriété, la liaison ne se met pas à jour dans le fichier de paramètres 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 de paramètres

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

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 ApplicationScopedSettingAttribute UserScopedSettingAttribute.
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, la sérialisation XML est utilisée à la place.
Détermine quels paramètres vont dans quels fichiers, selon 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 en code, consultez Guide pratique : Créer des paramètres d'application.

Emplacements des fichiers de paramètres

L’emplacement des fichiers app.exe.config et user.config varie 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 user.config résidera à l’emplacement spécifié par la Application.LocalUserAppDataPath propriété. Pour une application installée à l’aide de ClickOnce, ces deux fichiers se trouvent dans le répertoire de données ClickOnce sous %InstallRoot%\Documents et Paramètres\username\Local Paramètres.

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 appfichiers .exe.config et user.config 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 d’application et sécurité

Les paramètres d’application sont conçus pour fonctionner en mode de confiance partielle, un environnement restreint qui est la configuration par défaut pour les applications Windows Forms hébergées sur Internet ou sur 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 de l’application sont utilisés dans une application ClickOnce, le userfichier .config est stocké dans le répertoire de données ClickOnce. La taille du fichier .config de userl’application ne peut pas dépasser le quota de répertoires 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 application Paramètres, il existe un couplage libre entre la classe wrapper des paramètres des applications, dérivée du ApplicationSettingsBasefournisseur ou des fournisseurs de paramètres 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 stockera 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 fournisseur fourni pour GetPropertyValues déterminer le nom, le type et l’étendue de la propriété, ainsi que d’autres attributs de paramètres définis pour cette propriété.

Votre fournisseur devra 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 méthode Initialize qui n’accepte 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 demander à 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 de l’application Paramètres utilise ce fournisseur uniquement pour ces paramètres et 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é à partir de plusieurs threads simultanément, mais il écrira toujours au même emplacement de stockage. Par conséquent, l’architecture de paramètres d’application n’instanciera jamais 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, même s’il doit prendre en charge ApplicationScopedSettingAttribute au minimum et UserScopedSettingAttributedoit également prendre en charge DefaultSettingValueAttribute. Pour les attributs qu’il ne prend pas en charge, votre fournisseur doit simplement échouer sans notification. Il ne doit pas lever une exception. Si la classe de paramètres utilise une combinaison non valide d’attributs, toutefois, comme l’application ApplicationScopedSettingAttribute et UserScopedSettingAttribute le même paramètre, votre fournisseur doit lever une exception et cesser l’opération.

Partager via