Compartilhar via


Arquitetura das configurações do aplicativo

Este tópico descreve como a arquitetura das configurações de aplicativo funciona e explora recursos avançados da arquitetura, como as configurações agrupadas e as chaves de configurações.

A arquitetura das configurações de aplicativo dá suporte à configuração de configurações fortemente tipadas com escopo do aplicativo ou do usuário e a persistência das configurações entre as sessões do aplicativo. A arquitetura oferece um mecanismo de persistência padrão para salvar as configurações e carregá-las do sistema de arquivos local. A arquitetura também define interfaces para fornecer um mecanismo personalizado de persistência.

As interfaces são fornecidas para permitir que componentes personalizados mantenham suas próprias configurações quando forem hospedados em um aplicativo. Ao usar chaves de configurações, os componentes podem manter separadas as configurações para várias instâncias do componente.

configurando configurações

A arquitetura de configurações do aplicativo é usada no ASP.NET e no Windows Forms e contém várias classes base que são compartilhadas entre ambos os ambientes. O mais importante é SettingsBaseo , que fornece acesso às configurações por meio de uma coleção e fornece métodos de baixo nível para carregar e salvar configurações. Cada ambiente implementa sua própria classe derivada de para fornecer funcionalidade de SettingsBase configurações adicionais para esse ambiente. Em um aplicativo baseado em Windows Forms, todas as configurações do aplicativo devem ser definidas em uma classe derivada da ApplicationSettingsBase classe, que adiciona a seguinte funcionalidade à classe base:

  • Operações de carregar e salvar de nível mais alto

  • Suporte a configurações de escopo do usuário

  • Reverter as configurações do usuário para os padrões predefinidos

  • Atualizar as configurações de uma versão anterior do aplicativo

  • Validar configurações, antes que sejam alteradas ou antes que sejam salvas

As configurações podem ser descritas usando vários atributos definidos dentro do System.Configuration namespace, que são descritos em Atributos de configurações do aplicativo. Ao definir uma configuração, você deve aplicá-la com ou , que descreve se a configuração se aplica a todo o aplicativo ou ApplicationScopedSettingAttributeUserScopedSettingAttributeapenas ao usuário atual.

O exemplo de código a seguir define uma classe de configurações personalizadas com uma única configuração, 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

Persistência das configurações

A ApplicationSettingsBase classe em si não persiste ou carrega configurações, esse trabalho cabe ao provedor de configurações, uma classe que deriva de SettingsProvider. Se uma classe derivada de não especificar um provedor de ApplicationSettingsBase configurações por meio do SettingsProviderAttribute, o provedor padrão, , LocalFileSettingsProviderserá usado.

O sistema de configuração que foi lançado originalmente com o .NET Framework oferece suporte ao fornecimento de dados de configuração de aplicativo estático por meio do arquivo machine.config do computador local ou dentro de um app.arquivo exe.config que você implanta com seu aplicativo. A LocalFileSettingsProvider classe expande esse suporte nativo das seguintes maneiras:

  • As configurações de escopo do aplicativo podem ser armazenadas nos arquivos machine.config ou app.exe.config. O machine.config é sempre somente leitura, enquanto que o app.exe.config é restrito, por considerações de segurança, como somente leitura para a maioria dos aplicativos.

  • As configurações de escopo do usuário podem ser armazenadas em arquivos app.exe.config, caso em que são tratadas como padrões estáticos.

  • As configurações de escopo de usuário não padrão são armazenadas em um novo arquivo, user.config. Você pode especificar um padrão para uma configuração de escopo de usuário com DefaultSettingValueAttribute. Como as configurações de escopo do usuário geralmente mudam durante a execução do aplicativo, user.config é sempre leitura/gravação. Para obter mais informações, consulte Onde as configurações de escopo do usuário são armazenadas.

Todos os três arquivos de configuração armazenam as configurações no formato XML. O elemento XML de nível superior para configurações de escopo do aplicativo é <appSettings>, enquanto que o <userSettings> é usado para configurações de escopo do usuário. Um arquivo app.exe.config que contém configurações de escopo do aplicativo e padrões para configurações de escopo do usuário teria esta aparência:

<?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>

Para obter uma configuração dos elementos da seção de configurações de aplicativo de um arquivo de configuração, consulte Esquema de configurações de aplicativo.

Associações de configurações

As configurações de aplicativo usam a arquitetura de vinculação de dados dos Windows Forms para fornecer comunicação bidirecional das atualizações de configurações entre o objeto de configurações e os componentes. Se você usar o Visual Studio para criar configurações de aplicativo e atribuí-las às propriedades do componente, essas associações serão geradas automaticamente.

Você só pode vincular uma configuração de aplicativo a um componente que ofereça suporte à IBindableComponent interface. Além disso, o componente deve implementar um evento change para uma propriedade vinculada específica ou notificar as configurações do aplicativo de que a propriedade foi alterada por meio da INotifyPropertyChanged interface. Se o componente não implementar IBindableComponent e você estiver vinculando por meio do Visual Studio, as propriedades vinculadas serão definidas pela primeira vez, mas não serão atualizadas. Se o componente implementar, mas não oferecer suporte a notificações de alteração de propriedade, a associação não será atualizada no arquivo de IBindableComponent configurações quando a propriedade for alterada.

Alguns componentes do Windows Forms, como ToolStripItemo , não oferecem suporte a associações de configurações.

Serialização de configurações

Quando LocalFileSettingsProvider deve salvar as configurações no disco, ele executa as seguintes ações:

  1. Usa a reflexão para examinar todas as propriedades definidas em sua ApplicationSettingsBase classe derivada, localizando aquelas que são aplicadas com ou UserScopedSettingAttributeApplicationScopedSettingAttribute .

  2. Serializa a propriedade para o disco. Primeiro, ele tenta chamar o ConvertToString ou ConvertFromString no tipo associado TypeConverter. Se isso não for bem-sucedido, ela usará a serialização de XML.

  3. Determina quais configurações vão em quais arquivos, com base no atributo da configuração.

Se você implementar sua própria classe de configurações, poderá usar o SettingsSerializeAsAttribute para marcar uma configuração para serialização binária ou personalizada usando a SettingsSerializeAs enumeração. Para obter mais informações sobre como criar sua própria classe de configurações no código, consulte Como criar configurações de aplicativo.

Locais do arquivo de configurações

O local dos arquivos app.exe.config e user.config serão diferentes com base em como o aplicativo é instalado. Para um aplicativo baseado em Windows Forms copiado para o computador local, app.exe.config residirá no mesmo diretório que o diretório base do arquivo executável principal do aplicativo e user.config residirá no local especificado pela Application.LocalUserAppDataPath propriedade. Para um aplicativo instalado por meio do ClickOnce, ambos os arquivos residirão no Diretório de Dados do ClickOnce abaixo de %InstallRoot%\Documents and Settings\username\Local Settings.

O local de armazenamento desses arquivos será ligeiramente diferente se um usuário tiver habilitado perfis móveis, o que permite que um usuário defina configurações diferentes do Windows e do aplicativo quando estiver usando outros computadores em um domínio. Nesse caso, os aplicativos ClickOnce e os aplicativos não-ClickOnce terão seus apparquivos .exe.config e user.config armazenados em %InstallRoot%\Documents and Settings\username\Application Data.

Para obter mais informações sobre como o recurso de configurações de aplicativo funciona com a nova tecnologia de implantação, consulte ClickOnce e configurações de aplicativo. Para obter mais informações sobre o diretório de dados ClickOnce, consulte Acessando dados locais e remotos em aplicativos ClickOnce.

Segurança e configurações de aplicativo

As configurações de aplicativo são projetadas para trabalhar em confiança parcial, um ambiente restrito que é o padrão para aplicativos dos Windows Forms hospedados na Internet ou intranet. Não é necessária nenhuma permissão especial, além da confiança parcial, para usar as configurações de aplicativo com o provedor de configurações padrão.

Quando as configurações do aplicativo são usadas em um aplicativo ClickOnce, o userarquivo .config é armazenado no diretório de dados ClickOnce. O tamanho do arquivo .config do useraplicativo não pode exceder a cota de diretório de dados definida pelo ClickOnce. Para obter mais informações, consulte ClickOnce e as configurações de aplicativo.

Provedores de configurações personalizadas

Na arquitetura Configurações do Aplicativo, há um acoplamento flexível entre a classe wrapper de configurações de aplicativos, derivada de , e o provedor ou provedores de configurações associados, derivados de ApplicationSettingsBaseSettingsProvider. Essa associação é definida somente pela SettingsProviderAttribute aplicada à classe wrapper ou suas propriedades individuais. Se um provedor de configurações não for especificado explicitamente, o provedor padrão, , LocalFileSettingsProviderserá usado. Como resultado, essa arquitetura dá suporte à criação e uso de provedores de configurações personalizados.

Por exemplo, suponha que você queira desenvolver e usar o SqlSettingsProvider, um provedor que armazenará todos os dados de configurações em um banco de dados do Microsoft SQL Server. Sua SettingsProviderclasse -derived receberia essas informações em seu Initialize método como um parâmetro do tipo System.Collections.Specialized.NameValueCollection. Em seguida, você implementaria o GetPropertyValues método para recuperar suas configurações do armazenamento de dados e SetPropertyValues salvá-las. Seu provedor pode usar o fornecido para determinar o nome, o tipo e o SettingsPropertyCollection escopo da propriedade, bem como quaisquer outros atributos de configurações definidos para GetPropertyValues essa propriedade.

Seu provedor precisará implementar uma propriedade e um método cujas implementações podem não ser óbvias. A ApplicationName propriedade é uma propriedade abstrata de SettingsProvider; você deve programá-la para retornar o seguinte:

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

Sua classe derivada também deve implementar um método Initialize que não recebe argumentos e não retorna nenhum valor. Esse método não é definido pelo SettingsProvider.

Finalmente, você implementa IApplicationSettingsProvider em seu provedor para fornecer suporte para atualizar configurações, reverter configurações para seus padrões e atualizar configurações de uma versão de aplicativo para outra.

Depois de ter implementado e compilado seu provedor, você precisa instruir a classe de configurações para usar este provedor em vez do padrão. Você consegue isso através do SettingsProviderAttribute. Se aplicado a uma classe de configurações inteira, o provedor será usado para cada configuração definida pela classe; se aplicada a configurações individuais, a arquitetura de Configurações do Aplicativo usa esse provedor somente para essas configurações e usa LocalFileSettingsProvider para o restante. O exemplo de código a seguir mostra como instruir a classe de configurações para usar o provedor personalizado.

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

Um provedor pode ser chamado simultaneamente de vários threads, mas ele sempre gravará no mesmo local de armazenamento. Portanto, a arquitetura das configurações de aplicativo somente instanciará uma única instância de sua classe de provedor.

Importante

Você deve garantir que seu provedor seja thread-safe e permita que apenas um thread por vez grave nos arquivos de configuração.

Seu provedor não precisa oferecer suporte a todos os atributos de configurações definidos no namespace, embora deva no System.Configuration mínimo oferecer suporte e , e também deva oferecer suporte ApplicationScopedSettingAttributeUserScopedSettingAttributeDefaultSettingValueAttributea . Para os atributos aos quais ele não oferece suporte, o provedor deve apenas falhar, sem notificação. Ele não deve lançar uma exceção. No entanto, se a classe settings usar uma combinação inválida de atributos, como aplicar ApplicationScopedSettingAttribute e para a mesma configuração, seu provedor deverá lançar uma exceção e UserScopedSettingAttribute interromper a operação.

Confira também