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 Settingsclasse 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.LoadFrome 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 SerializableAttributeclasses marcadas ou implementadas IXmlSerializablepara 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).
Crie um arquivo config.xml e defina sua ação de construção como AddInContent nas propriedades do VS para o arquivo.
Para adicionar isso com base no comentário, já que você está fazendo isso em C #, eu supunha que você estivesse usando o Visual Studio para criar seu suplemento. A partir daí, se você adicionar um arquivo de configuração XML a partir da opção new file e o nomear config.xml, ele criará um arquivo vazio padrão. A partir daí, você pode especificar as configurações xml do valor da chave na tag appSettings da mesma forma que um arquivo de configuração xml normal e, em seguida, fazer referência a elas no código como faria normalmente. Para alterar sua ação de compilação, quando você tiver o arquivo selecionado no VS, observe a janela de propriedades e deve haver uma configuração de ação de compilação. Selecione isso e ele mostrará uma lista suspensa das opções disponíveis, escolha AddInContent na lista.
fonte