Tout d'abord, je n'ai pas essayé d'utiliser Config.esriaddinx à cette fin, mais je ne le recommanderais pas. Il est destiné à la configuration du complément lui-même, pas nécessairement aux données utilisateur, et vous ne voulez probablement pas mélanger les deux.
Cela fait un moment que je n'ai pas traité cela moi-même, donc je peux être un peu flou sur les détails, mais il y a plusieurs problèmes avec l'utilisation des fichiers de configuration dans les compléments ArcGIS: Complément ArcMap avec app.settings ne reconnaissant pas l'application Les changements de .config?
En particulier, le répertoire dans lequel le complément est extrait est écrasé à chaque démarrage de l'application, vous ne pouvez donc pas vraiment persister les modifications des paramètres. Si vos paramètres ne changent jamais ou ne changent qu'avec chaque nouvelle version de votre complément, ce n'est probablement pas un problème.
Si, cependant, vous souhaitez rendre votre complément configurable par l'utilisateur final, vous devez stocker les informations configurables par l'utilisateur ailleurs afin qu'elles ne soient pas écrasées. Je suggère d'utiliser le dossier Application Data de l'utilisateur , dont vous pouvez déterminer le chemin par programme comme suit:
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)
Je suggérerais également de le placer dans un sous-dossier nommé d'après votre complément. Mais essentiellement, vous chargeriez et enregistreriez dans un fichier à cet emplacement au lieu de lire les paramètres de la Settings
classe de votre complément ou du fichier de configuration dans le répertoire du complément. Si vous souhaitez utiliser la configuration .NET pour cela, je suggère de lire les paramètres d'application et ConfigurationManager
.
L'autre problème que j'ai rencontré concerne l'utilisation de sections de configuration personnalisées lors de l'utilisation de la configuration .NET. L'utilisation Assembly.LoadFrom
et la gestion de l'AssemblyResolve
événement ont été la solution à ce problème particulier, bien que dans ce cas j'ai fini par ne pas utiliser la configuration .NET pour cela et pour d'autres raisons.
En fonction de la complexité de votre scénario de configuration, vous pouvez, comme je l'ai fait, éviter complètement d'utiliser le système de configuration .NET et utiliser à la place une autre méthode de lecture et d'écriture des informations de configuration. J'ai fini par utiliser des SerializableAttribute
classes marquées ou des classes implémentées IXmlSerializable
à cet effet dans l'un des compléments les plus complexes que j'ai créés, qui comprenaient des paramètres configurables par l'utilisateur tels que des listes de couches, des paramètres de connexion, etc. Je recommanderais de lire la sérialisation d'objets dans. NET , Présentation de la sérialisation XML et comment implémenter correctement IXmlSerializable si vous êtes intéressé par cette approche.
Il semble que le vôtre soit dans le même sens, donc c'est à vous de décider, mais j'ai trouvé l'approche de sérialisation XML préférable à la configuration .NET pour tous, sauf le plus simple des scénarios de configuration (types de données simples, pas de hiérarchies / collections).