Plugin pour utiliser son propre app.config

Question

J'ai finalement réussi à construire une solution de travail d'une architecture de plugin avec l'aide de certains gars ici, mais maintenant un nouveau problème se pose.

Mon application d'hébergement utilise son fichier app.config pour certaines valeurs par défaut de l'assembly d'exécution (qui est un service Windows).

Chaque plugin devrait être capable de charger ses propres paramètres à partir d'un fichier de paramètres de plugin séparé car l'hôte ne devrait pas être informé des paramètres du plugin. Dans le projet de plugin j'ai ajouté un fichier app.config ainsi (avec quelques paramètres et une chaîne de connexion) pour que je puisse instancier la classe Properties.Settings et utiliser ses propriétés dans le code du plugin. Le problème est quand je change les paramètres dans le app.config du plugin (qui est construit comme plugin.dll.config) Je ne peux pas voir ces changements dans le plugin lui-même, qui utilise toujours les paramètres de conception .

Existe-t-il un moyen de charger les paramètres app.config dans chaque plugin pour que la classe Properties.Settings générée fonctionne? Sinon, existe-t-il un autre moyen de charger un fichier de paramètres basé sur app.config dans le plugin? Je prévois d'ajouter une méthode LoadConfiguration dans l'interface IPlugin afin que chaque plugin charge ses propres paramètres.

Answer 1

Est-ce que quelque chose comme ConfigurationManager.OpenMappedExeConfiguration aiderait ici? Vous pouvez créer un objet Configuration lisant dans les valeurs d'un fichier spécifique.

Answer 2

Vous travaillez avec l'architecture de app.config. Vous obtenez un fichier app.config par fichier exécutable (EXE, pas DLL). L'exécutable se lance, crée son AppDomain et charge MyApp.exe.config. Vous pouvez ajouter des objets app.config dans Visual Studio, mais ils sont ignorés pour les DLL. Je pense que ce que vous voulez faire est de copier manuellement le XML à partir du fichier dll.config et de le coller dans le niveau de l'application app.config. (Je suis sûr qu'il existe un moyen d'automatiser cela en utilisant TeamBuild ou un tel.) Les valeurs substituées seront alors disponibles pour votre classe Properties.Settings.

Answer 3

Je préfère construire et utiliser un plugin de type IConfigManager. Ce travail consiste à expliquer comment la configuration est stockée. Vous recevez une instance de celui-ci via l'injection de dépendance. De cette façon, l'implémentation IConfigManager peut charger des paramètres à partir de plusieurs fichiers .config, à partir du réseau, d'une base de données ou de toute autre source. Je l'utilise également pour fournir des valeurs par défaut basées sur l'utilisateur, la machine et/ou l'application - qui peuvent être remplacées par l'utilisateur, par ex.

D'autres avantages de cette méthode sont que les paramètres peuvent être conservés de manière cohérente dans tous les plugins - sans les plugins, l'endroit où votre plugin stocke ses paramètres peut changer de manière transparente (de. config to other) et enfin, IConfigManager peut être raillé pendant les tests unitaires pour simuler différentes situations.

J'espère que cela aide.

Answer 4

Je suis un collègue d'Erik. Comme il passera des vacances bien méritées dans les prochaines semaines, je vais développer un peu plus sur ce sujet.

Dans nos plugins, nous utilisons plusieurs instances de clients du service WCF. La chose intéressante de ces services est qu'ils viennent avec des sections app.config que vous pouvez utiliser pour configurer le comportement, le type de service, la sécurité, etc.

Maintenant, quand nous chargeons nos plugins, ces sections sont manquantes dans config et par conséquent, les points de terminaison corrects ne peuvent pas être trouvés. Bien sûr, nous pourrions les mettre dans le code, mais ce genre de choses ébranle la possibilité de définir d'autres options de configuration le long du chemin en cas de besoin. Nous pourrions vouloir implémenter ws-security par exemple.

Nous avons donc besoin d'un moyen de charger ces configurations afin que les plugins puissent y lire leurs paramètres respectifs. Nous pourrions bien sûr fusionner toutes les configs en une seule, mais cela élimine la méthode "juste plugin" puisque vous devriez gérer les configs à côté de l'installation du plugin.

Je pensais à la création d'un petit outil qui fusionnerait la configuration 'master' avec toutes les configurations placées dans un sous-répertoire du projet et remplacerait le fichier .exe.config par celui-là. Je pense que cela fonctionnerait, mais je me demandais si .NET ne fournit pas de meilleures options. Les AppDomains multiples ne fonctionnent pas car les plugins doivent interagir entre eux (modèle fournisseur/consommateur) et nous ne souhaitons pas passer à l'accès distant à cause de ce problème. Mise à jour: J'ai corrigé la plupart des problèmes en utilisant le ConfigurationManager pour ouvrir les configurations existantes pour lire appSettings. Comme pour les clients WCF; Vous pouvez charger la configuration du point de terminaison/liaison pour le serveur et le client comme indiqué ici: http://weblogs.asp.net/cibrax/archive/2007/10/19/loading-the-wcf-configuration-from-different-files-on-the-client-side.aspx

Answer 5

Vous pouvez faire en sorte que chaque plug-in lise sa propre ConfigurationSection puis, dans le fichier de configuration principal, utilisez le paramètre ConfigSource pour pointer vers un fichier externe. (Voir ce link pour plus d'informations)

Vous n'échapperez pas complètement aux informations de configuration du plugin dans le fichier app.config principal mais au moins les paramètres spécifiques du plugin sont dans des fichiers séparés.

Answer 6

Je préfère généralement éviter tout le désordre app.config en créant un fichier Xml dédié que l'hôte traite avec les paramètres du plugin à l'intérieur. Le Xml ressemblerait à quelque chose comme ceci:

<root> 
    <Settings> 
     Here's where anything specific to the app goes. 
    </Settings> 
    <plugins> 
     <plugin type="mylibrary.myclass"> 
      Here I let the plugin serialize itself however it wants to. 
     </plugin> 
    </plugins> 
</root> 

L'application d'hébergement crée alors le plug-in à partir du type attribut et teste si la classe implémente ISerializable; si c'est le cas, le plugin se désérialisera. C'est un peu effrayant d'avoir les plugins en ligne avec les paramètres de l'application, mais si vous chargez la sous-chaîne de Xml dans un nouveau XmlReader alors vous n'avez pas à vous soucier d'une erreur dans le plugin de lire trop loin dans le Xml chaîne.