Contexte lors du chargement des assemblages via Structuremap

Question

Je souhaite charger les plugins de la même manière que shown here, mais les assemblys chargés ne semblent pas partager le même contexte.

Essayer de résoudre le problème Je viens de construire une petite pointe contenant deux assemblages. Une application de console et une bibliothèque. L'application console contient l'interface IPlugin et n'a aucune référence à la DLL du plugin.

Je suis le balayage du plug-in dir en utilisant une convention d'enregistrement personnalisé:

ObjectFactory.Initialize(x => x.Scan(s => 
    { 
     s.AssembliesFromPath(@"..\Plugin"); 
     s.With(new PluginScanner()); 
    })); 

public void Process(Type type, Registry registry) 
{ 
    if (!type.Name.StartsWith("P")) return; 

    var instance = ObjectFactory.GetInstance(type); 
    registry.For<IPlugin>().Add((IPlugin)instance); 
} 

qui thows une exception coulée invalide en disant « ne peut pas convertir le type de plug-in pour IPlugin ».

En outre, si je viens construis l'instance (qui fonctionne très bien par ailleurs) et essayez d'accéder ObjectFactory dans le plugin ObjectFactory.WhatDoIHave() montre que plug-in instance et instance hôte ne partagent même pas le même récipient exemple.

Expérimentation autour avec MEF, Structuremap et le chargement manuel de l'assembly avec Assembly.Load ("Plugin") montre si chargé avec Assembly.Load il fonctionne très bien. Des idées comment je peux résoudre cela pour travailler avec l'analyse d'assemblage de StructureMaps?

Answer 1

J'ai trouvé la solution.

Prenez cette structure:

\Plugins 
     \Plugin.dll 
     \core.dll 
\app.exe 
\core.dll 

Ainsi IPlugin est défini dans core.dll. Mon plugin a une dépendance au noyau, ainsi que mon application. Mon application charge le core.dll et charge le plugin.dll qui recherchera sa dépendance dans son dossier plugin. Chargement core.dll une seconde fois.

Si j'obtiens un type de Plugin.dll et que j'essaie de le convertir en IPlugin dans le noyau, l'application essaie de lancer un objet qui est sous-classe de {PluginDir} Core.IPlugin vers {AppDir} Core.IPlugin. Cela échouera parce que les interfaces sont différentes.

\Plugin.dll 
\app.exe 
\core.dll  

Ce scénario fonctionnera correctement car à la fois app.exe et plugin.dll utiliseront le même core.dll.