Sections de configuration personnalisées dans les assemblages d'exportation MEF

Question

J'ai un assemblage qui contient des classes qui importent un certain nombre de classes provenant d'assemblages différents qui ne sont pas référencés au moment de la compilation mais qui sont découverts au moment de l'exécution via un catalogue de répertoires. Les classes exportatrices souhaitent définir des sections de configuration personnalisées pour le fichier de configuration de l'application hôte de l'assemblage importateur. Cependant, comme l'application hôte de l'assemblage importé ne connaît pas les assemblages exportateurs au moment de la compilation, elle ne peut pas charger l'assemblage pour utiliser les implémentations des gestionnaires de sections personnalisées qu'il contient.

J'ai trouvé un moyen de contourner ce problème en plaçant les assemblages d'exportation dans le même dossier que l'assemblage de l'application hôte de l'assemblage d'importation. Mais j'aimerais permettre à d'autres développeurs de configurer le dossier de leur choix pour contenir leurs assemblages d'exportation.

Une chose que je peux faire est de copier le contenu du dossier configuré du développeur dans le dossier de l'hôte au démarrage. Mais je préfère éviter ces pièces mobiles supplémentaires et ce code à maintenir si je le peux. Existe-t-il un meilleur moyen de contourner ce problème ? Existe-t-il un moyen de diriger une application vers des répertoires supplémentaires lorsqu'elle recherche des assemblages qui définissent des sections de configuration personnalisées ?

Answer 1

J'ai rencontré le même problème en utilisant StructureMap pour découvrir des assemblages de manière dynamique. Le ConfigurationManager semble rechercher l'assemblage spécifié pour la ConfigurationSection uniquement dans le Bin-Folder et le GAC. Cela ne semble pas fonctionner même si l'assembly a été chargé dans l'AppDomain courant.

Mais le fait que l'assemblage de la section de configuration soit déjà chargé peut être utilisé pour une solution de contournement simple :

AppDomain.CurrentDomain.AssemblyResolve += (o, args) =>
        {
            var loadedAssemblies = AppDomain.CurrentDomain.GetAssemblies();
            return loadedAssemblies.FirstOrDefault(asm => asm.FullName == args.Name);
        };

L'événement AssemblyResolve est déclenché lorsque le CLR ne parvient pas à trouver un certain assemblage. Veillez à enregistrer le rappel avant le premier appel à GetSection().

Cela me convient.

Answer 2

Pour autant que je sache, les sections de configuration ne sont lues que lorsqu'on y accède par l'intermédiaire de GetSection() . Si le code de votre module est le seul à appeler ConfigurationManager.GetSection("myModuleConfigSection") alors cela n'aura probablement pas d'importance, car à ce stade, l'assemblage a été chargé dans l'application AppDomain . Si cette section est lue avant que votre assemblage ne soit chargé dans le fichier AppDomain j'imagine que vous obtiendrez une exception.

Vous pourriez probablement ajouter le chemin d'accès à votre module au chemin d'accès au module privé (private bin path), le chemin d'accès au module privé (private bin path). AppDomain utilisation de la résolution de l'assemblée. L'ajout d'un chemin supplémentaire permet de résoudre les assemblages qui ne sont pas encore chargés.