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 d'application permet de définir des paramètres fortement typés avec une portée d’application ou d’utilisateur et assure 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 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 de 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 classe ApplicationSettingsBase, ce qui ajoute les fonctionnalités suivantes à la classe de base :
Opérations de chargement et d’enregistrement de niveau supérieur
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 de noms System.Configuration ; ces attributs 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, qui décrit 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 classe ApplicationSettingsBase ne se conserve pas ou ne charge pas les paramètres ; ce travail appartient au fournisseur de paramètres, classe qui dérive de SettingsProvider. Si une classe dérivée de ApplicationSettingsBase ne spécifie pas de fournisseur de paramètres via le SettingsProviderAttribute, 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 fichier app.exe.config que vous déployez avec votre application. La classe LocalFileSettingsProvider 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 queapp.exe.config est en lecture seule pour la plupart des applications en raison des considérations de sécurité.Les paramètres définis par l’utilisateur peuvent être stockés dans des fichiers
app.exe.config, auquel cas ils sont traités comme des valeurs par défaut statiques.Les paramètres à portée d'utilisateur non par défaut sont stockés dans un nouveau fichier, user.config. Vous pouvez définir une valeur par défaut pour un paramètre à portée d'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 à portée d'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 fichier app.exe.config qui contient à la fois les paramètres à l'échelle de l'application et les paramètres par défaut pour l'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.
Paramètres de liaisons
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 de INotifyPropertyChanged. Si le composant n’implémente pas IBindableComponent et que vous effectuez une liaison via Visual Studio, les propriétés liées sont 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 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 des paramètres
Lorsque LocalFileSettingsProvider 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 classe dérivée ApplicationSettingsBase, en recherchant celles qui sont appliquées avec ApplicationScopedSettingAttribute ou 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, il utilise la sérialisation XML à la place.
Détermine quels paramètres vont dans quels fichiers, en fonction de l’attribut du paramètre.
Si vous implémentez votre propre classe de paramètres, vous pouvez utiliser l'SettingsSerializeAsAttribute 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èrent 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 'utilisateur.config résidera dans l’emplacement spécifié par la propriété Application.LocalUserAppDataPath. 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\nom d’utilisateur\Paramètres locaux.
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 fichiers.config utilisateur stockés sous %InstallRoot%\Documents et paramètres\nom d’utilisateur\Données d’application.
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 fichier user.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 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 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 la SettingsProviderAttribute appliquée à 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, LocalFileSettingsProvider, est 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 classe dérivée de SettingsProviderreçoit ces informations dans sa méthode Initialize en tant que paramètre de type System.Collections.Specialized.NameValueCollection. Vous devez ensuite implémenter la méthode GetPropertyValues pour récupérer vos paramètres à partir du magasin de données et SetPropertyValues les enregistrer. Votre fournisseur peut utiliser le SettingsPropertyCollection fourni pour GetPropertyValues pour déterminer le nom, le type et l’étendue de la propriété, ainsi que les autres attributs de paramètres 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 propriété ApplicationName est une propriété abstraite de SettingsProvider; vous devez le 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 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 cette opération par le biais de la 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 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 de noms System.Configuration, même s’il doit au minimum prendre en charge ApplicationScopedSettingAttribute et UserScopedSettingAttribute, et doit également prendre en charge DefaultSettingValueAttribute. Pour ces attributs qu’il ne prend pas en charge, votre fournisseur doit simplement échouer sans notification ; il ne doit pas lever d’exception. Si la classe settings utilise une combinaison non valide d’attributs, toutefois, comme l’application d'ApplicationScopedSettingAttribute et de UserScopedSettingAttribute au même paramètre, votre fournisseur doit lever une exception et cesser l’opération.
Voir aussi
.NET Desktop feedback