En primer lugar, no he intentado usar Config.esriaddinx para este propósito, pero yo no lo recomiendo. Está diseñado para la configuración del complemento en sí mismo, no necesariamente los datos de usuario, y usted probablemente no quiere mezclar los dos.
Ha sido un tiempo desde que he tratado con esto por mí mismo, así que puede ser un poco difusa en los detalles, pero hay varios problemas con el uso de archivos de configuración en ArcGIS complementos: ESRI ArcMap Complemento con de la aplicación.la configuración de no reconocer a la aplicación.los cambios de configuración
En particular, el directorio el complemento que se extrae se sobrescribe cada vez que se inicia la aplicación, así que realmente no pueden persistir los cambios a la configuración de allí. Si su configuración no cambiar nunca o sólo cambian con cada nueva versión de su complemento, a continuación, probablemente esta no sea una preocupación.
Sin embargo, si usted desea hacer su complemento en configurables por el usuario final, entonces usted necesita para almacenar la configurable por el usuario de la información en otros lugares para que no se sobrescriban. Yo sugeriría utilizando el usuario de Datos de la Aplicación de la carpeta, cuya ruta de acceso puede determinar mediante programación así:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
También sugiero ponerlo en una subcarpeta con el nombre después de su complemento. Pero básicamente lo que sería de carga desde y guardar a un archivo en esa ubicación en lugar de la lectura de la configuración de su complemento en la Settings de la clase o el archivo de configuración en el complemento del directorio. Si desea utilizar .Configuración de RED para este entonces le sugiero leer sobre la Configuración de la Aplicación y ConfigurationManager.
El otro problema que he tenido es con el uso de secciones de configuración personalizada cuando se utiliza .Configuración de RED. El uso de Assembly.LoadFrom y el manejo de la AssemblyResolve evento fue la solución para ese problema en particular, aunque en ese caso yo no terminaron de usar .Configuración de RED para esa y otras razones.
Dependiendo de la complejidad de su configuración escenario, se podría, como lo hice yo, descartar el uso de la .Configuración de RED del sistema completo y en lugar de utilizar algún otro método de lectura y escritura de información de configuración. Terminé usando SerializableAttribute-marcado clases o clases que implementan IXmlSerializable para este propósito en uno de los complementos más complejos que he creado que incluye configurable por el usuario configuración, tales como la lista de capas, ajustes de conexión, etc. Yo recomendaría la lectura de la Serialización de Objetos .NET, la Introducción de la Serialización XML y Cómo Implementar IXmlSerializable Correctamente si usted está interesado en ese enfoque.
Suena como que es tuyo a lo largo de las líneas de la misma forma que a usted, pero me he encontrado con la serialización XML enfoque a ser preferible .Configuración de RED para todos, pero el más simple de los escenarios de configuración (tipos de datos simples, sin jerarquías/colecciones).
