En primer lugar, no he intentado usar Config.esriaddinx para este propósito, pero no lo recomendaría. Está destinado a la configuración del complemento en sí, no necesariamente a los datos del usuario, y probablemente no desee mezclar los dos.
Ha pasado un tiempo desde que me ocupé de esto, así que puedo ser un poco confuso con los detalles, pero hay varios problemas con el uso de archivos de configuración en los complementos de ArcGIS: ArcMap Add-in con app.settings no reconoce la aplicación .config cambios?
En particular, el directorio en el que se extrae el complemento se sobrescribe cada vez que se inicia la aplicación, por lo que realmente no puede persistir los cambios en la configuración allí. Si su configuración nunca cambia o solo cambia con cada nueva versión de su complemento, entonces esto probablemente no sea una preocupación.
Sin embargo, si desea hacer que su complemento sea configurable por el usuario final, entonces necesita almacenar la información configurable por el usuario en otro lugar para que no se sobrescriba. Sugeriría usar la carpeta de Datos de aplicación del usuario , cuya ruta puede determinar mediante programación de la siguiente manera:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
También sugeriría ponerlo en una subcarpeta con el nombre de su complemento. Pero esencialmente estaría cargando y guardando en un archivo en esa ubicación en lugar de leer la configuración de la Settings
clase de su complemento o el archivo de configuración en el directorio del complemento. Si desea utilizar la configuración .NET para esto, le sugiero que lea la Configuración de la aplicación y ConfigurationManager
.
El otro problema que he tenido es usar secciones de configuración personalizadas cuando uso la configuración .NET. Usar Assembly.LoadFrom
y manejar elAssemblyResolve
evento fue la solución a ese problema en particular, aunque en ese caso terminé sin usar la configuración .NET por esa y otras razones.
Dependiendo de la complejidad de su escenario de configuración, podría, como lo hice, evitar el uso del sistema de configuración .NET por completo y en su lugar utilizar algún otro método para leer y escribir información de configuración. Terminé usando SerializableAttribute
clases marcadas o clases que se implementaron IXmlSerializable
para este propósito en uno de los complementos más complejos que creé, que incluía configuraciones configurables por el usuario, como listas de capas, configuraciones de conexión, etc. Recomendaría leer la serialización de objetos en. NET , presentando la serialización XML y cómo implementar IXmlSerializable correctamente si está interesado en ese enfoque.
Parece que el suyo está en la misma línea, por lo que depende de usted, pero descubrí que el enfoque de serialización XML es preferible a la configuración de .NET para todos los escenarios de configuración, excepto los más simples (tipos de datos simples, sin jerarquías / colecciones).