CODEWITHSUNDEEP
metadatamef
Aaron Powell
Aaron Powell

Reputation: 25099

MEF Metadata from the exported parts

I'm looking to use MEF for a plugin system for an application I'm building. Each component I want to have an identifier on (a GUID) which I want to be able to look up against. But this ID is also something that is useful when working with the exported part.

Is there a way that I can have a Metadata attribute which contains the ID as well as a property (or method) on the exported part, short of having developers fill it out twice or use reflection to find it from the attribute?

Upvotes: 4

Views: 1902

Answers (2)

Wim Coenen
Wim Coenen

Reputation: 66723

Put the GUID in a constant, and use it for both a property and the metadata:

[Export(typeof(IFoo))]
[ExportMetadata("GUID", _guid)]
public class Foo : IFoo
{
    private const string _guid = "abc";

    public string Guid { get { return _guid; } }
}

Note that you can't use the Guid type instead of string, as that is not permitted by the const keyword.

Upvotes: 0

Matthew Abbott
Matthew Abbott

Reputation: 61589

It's likely to be a mixture of a MEF metadata attribute, and an abstract base class. I would define my plugin contract as something like:

public interface IPluginMetadata
{
  Guid PluginId { get; }
}

public interface IPlugin : IPluginMetadata
{
  void Initialise();
}

I've enforced that the IPlugin interface also inherits our metadata contract IPluginMetadata. Next, we can create a custom export attribute:

[AttributeUsage(AttributeTargets.Class, Inherit = true), MetadataAttribute]
public class ExportPluginAttribute : ExportAttribute, IPluginMetadata
{
  public ExportPluginAttribute(string pluginId) : base(typeof(IPlugin))
  {
    if (string.IsNullOrEmpty(pluginId))
      throw new ArgumentException("'pluginId' is required.", "pluginId");

    PluginId = new Guid(pluginId);
  }

  public Guid PluginId { get; private set; }
}

You don't need to decorate the export attribute with the metadata contract IPluginMetadata, as MEF will project the properties anyway, but I prefer to do so, so if I do introduce changes to my metadata contract, then my export attribute should be updated too. No harm, no foul.

Once we've done this, we can define an abstract base class from which to implement our plugin contract:

public abstract class PluginBase : IPlugin
{
  protected PluginBase()
  {
    var attr = GetType()
      .GetCustomAttributes(typeof(ExportPluginAttribute), true)
      .Cast<ExportPluginAttribute>()
      .SingleOrDefault();

    PluginId = (attr == null) ? Guid.Empty : attr.PluginId;
  }

  public virtual Guid PluginId { get; private set; }

  public abstract void Initialise();
}

We can then grab the custom attribute through the abstract class's constructor, and apply the property accordingly. That we can do:

public IPlugin GetPlugin(Guid id)
{
  var plugin = container
    .GetExports<IPlugin, IPluginMetadata>()
    .Where(p => p.Metadata.PluginId == id)
    .Select(p => p.Value)
    .FirstOrDefault();

  return plugin;
}

And also:

[ExportPlugin("BE112EA1-1AA1-4B92-934A-9EA8B90D622C")]
public class MyPlugin : PluginBase
{
  public override Initialise()
  {
    Console.WriteLine(PluginId);
  }
}

We can see that out PluginId is exposed both through exported metadata, as well as a property of our plugin.

That code is all untested, but I hope it pushes you in the right direction.

Upvotes: 7

Related Questions