Primeiro, eu não tentei usar o Config.esriaddinx para esse fim, mas não o recomendaria. Ele se destina à configuração do suplemento em si, não necessariamente aos dados do usuário, e você provavelmente não deseja misturar os dois.
Já faz um tempo desde que eu lidei com isso sozinho, para que eu fique um pouco confuso com os detalhes, mas há vários problemas com o uso de arquivos de configuração nos suplementos do ArcGIS: Suplemento do ArcMap com app.settings que não reconhece o aplicativo .config muda?
Em particular, o diretório para o qual o suplemento é extraído é sobrescrito toda vez que o aplicativo é iniciado, portanto, não é possível persistir alterações nas configurações. Se suas configurações nunca forem alteradas ou apenas forem alteradas a cada nova versão do seu suplemento, isso provavelmente não será uma preocupação.
Se, no entanto, você desejar tornar seu suplemento configurável pelo usuário final, será necessário armazenar as informações configuráveis pelo usuário em outro local para que não sejam substituídas. Eu sugeriria o uso da pasta Application Data do usuário, cujo caminho você pode determinar programaticamente da seguinte maneira:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Eu também sugeriria colocá-lo em uma subpasta com o nome do seu suplemento. Mas, essencialmente, você estaria carregando e salvando em um arquivo nesse local, em vez de ler as configurações da Settings
classe do seu suplemento ou o arquivo de configuração no diretório do suplemento. Se você quiser usar a configuração do .NET para isso, sugiro ler as Configurações do aplicativo e ConfigurationManager
.
O outro problema que tive foi com o uso de seções de configuração personalizadas ao usar a configuração do .NET. Usar Assembly.LoadFrom
e manipular oAssemblyResolve
evento foi a solução para esse problema específico, embora nesse caso eu acabasse não usando a configuração do .NET por esse e outros motivos.
Dependendo da complexidade do seu cenário de configuração, você pode, como eu, evitar o uso completo do sistema de configuração .NET e, em vez disso, usar outro método de leitura e gravação de informações de configuração. Acabei usando SerializableAttribute
classes marcadas ou implementadas IXmlSerializable
para esse fim em um dos suplementos mais complexos que criei, que incluíam configurações configuráveis pelo usuário, como listas de camadas, configurações de conexão etc. Eu recomendaria a leitura de Serialização de objetos. NET , Introdução à serialização XML e como implementar IXmlSerializable corretamente, se você estiver interessado nessa abordagem.
Parece que o seu está na mesma linha, então é com você, mas achei a abordagem de serialização XML preferível à configuração do .NET para todos, exceto os cenários de configuração mais simples (tipos de dados simples, sem hierarquias / coleções).