Question

As explained in these questions I’m trying to build an application that consists of a host and multiple task processing clients. With some help I have figured out how to discover and serialize part definitions so that I could store those definitions without having to have the actual runtime type loaded.

The next step I want to achieve (or next two steps really) is that I want to split the composition of parts from the actual creation and connection of the objects (represented by those parts). So if I have a set of parts then I would like to be able to do the following thing (in pseudo-code):

public sealed class Host
{
    public CreationScript Compose()
    {
        CreationScript result;
        var container = new DelayLoadCompositionContainer(
            s => result = s);
        container.Compose();
        return script;
    }

    public static void Main()
    {
        var script = Compose();

        // Send the script to the client application
        SendToClient(script);
    }
}

// Lives inside other application
public sealed class Client
{
    public void Load(CreationScript script)
    {
        var container = new ScriptLoader(script);
        container.Load();
    }

    public static void Main(string scriptText)
    {
        var script = new CreationScript(scriptText);
        Load(script);
    }
}

So that way I can compose the parts in the host application, but actually load the code and execute it in the client application. The goal is to put all the smarts of deciding what to load in one location (the host) while the actual work can be done anywhere (by the clients).

Essentially what I’m looking for is some way of getting the ComposablePart graph that MEF implicitly creates.

Now my question is if there are any bits in MEF that would allow me to implement this kind of behaviour? I suspect that the provider model may help me with this but that is a rather large and complex part of MEF so any guidelines would be helpful.

Answer 1

From lots of investigation it seems that is not possible to separate the composition process from the instantiation process in MEF so I have had to create my own approach for this problem. The solution assumes that the scanning of plugins results in having the type, import and export data stored somehow.

In order to compose parts you need to keep track of each part instance and how it is connected to other part instances. The simplest way to do this is to make use of a graph data structure that keeps track of which import is connected to which export.

public sealed class CompositionCollection
{
    private readonly Dictionary<PartId, PartDefinition> m_Parts;
    private readonly Graph<PartId, PartEdge> m_PartConnections;

    public PartId Add(PartDefinition definition)
    {
        var id = new PartId();
        m_Parts.Add(id, definition);
        m_PartConnections.AddVertex(id);

        return id;
    }

    public void Connect(
        PartId importingPart, 
        MyImportDefinition import,
        PartId exportingPart,
        MyExportDefinition export)
    {
        // Assume that edges point from the export to the import
        m_PartConnections.AddEdge(
            new PartEdge(
                exportingPart,
                export,
                importingPart,
                import));
    }
}

Note that before connecting two parts it is necessary to check if the import can be connected to the export. In other cases MEF does that but in this case we’ll need to do that ourselves. An example of how to approach that is:

public bool Accepts(
    MyImportDefinition importDefinition, 
    MyExportDefinition exportDefinition)
{
    if (!string.Equals(
        importDefinition.ContractName, 
        exportDefinition.ContractName, 
        StringComparison.OrdinalIgnoreCase))
    {
        return false;
    }

    // Determine what the actual type is we're importing. MEF provides us with 
    // that information through the RequiredTypeIdentity property. We'll 
    // get the type identity first (e.g. System.String)
    var importRequiredType = importDefinition.RequiredTypeIdentity;

    // Once we have the type identity we need to get the type information
    // (still in serialized format of course)
    var importRequiredTypeDef = 
        m_Repository.TypeByIdentity(importRequiredType);

    // Now find the type we're exporting
    var exportType = ExportedType(exportDefinition);
    if (AvailableTypeMatchesRequiredType(importRequiredType, exportType))
    {
        return true;
    }

    // The import and export can't directly be mapped so maybe the import is a 
    // special case. Try those
    Func<TypeIdentity, TypeDefinition> toDefinition = 
        t => m_Repository.TypeByIdentity(t);
    if (ImportIsCollection(importRequiredTypeDef, toDefinition) 
        && ExportMatchesCollectionImport(
            importRequiredType, 
            exportType, 
            toDefinition))
    {
        return true;
    }

    if (ImportIsLazy(importRequiredTypeDef, toDefinition) 
        && ExportMatchesLazyImport(importRequiredType, exportType))
    {
        return true;
    }

    if (ImportIsFunc(importRequiredTypeDef, toDefinition) 
        && ExportMatchesFuncImport(
            importRequiredType, 
            exportType, 
            exportDefinition))
    {
        return true;
    }

    if (ImportIsAction(importRequiredTypeDef, toDefinition) 
        && ExportMatchesActionImport(importRequiredType, exportDefinition))
    {
        return true;
    }

    return false;
}

Note that the special cases (like IEnumerable<T>, Lazy<T> etc.) require determining if the importing type is based on a generic type which can be a bit tricky.

Once all the composition information is stored it is possible to do the instantiation of the parts at any point in time because all the required information is available. Instantiation requires a generous helping of reflection combined with the use of the trusty Activator class and will be left as an exercise to the reader.