Andrew Whitechapel : MEF

MEF in Office?

andreww — Wed, 08 Apr 2009 03:14:00 GMT

In my last post, I looked briefly at MEF, and I’m wondering how this model can be applied to Office add-ins. The Office add-in model itself already achieves a level of dynamic composition, by virtue of the fact that the set of add-ins to be loaded is only discovered at runtime. However, even though the model is similar at a high level, Office itself does not use MEF.

Nonethless, MEF could perhaps be useful in an Office context. For example, suppose you want to build the add-in itself as a composite. That is, suppose your total add-in functionality is made up of components – and furthermore, you want to discover these components at runtime, instead of statically linking them at design-time.

In this post, I’ll translate the simple console MEF app from my previous post to an Office add-in.

This turned out to be remarkably easy. I used the same ‘Interface’ assembly, the same ‘Implementation’ assembly, and the same ‘Alternate’ implementation assembly. The only difference was that I built a VSTO add-in instead of a console app. This is the code in my add-in class:

[Import]

public Interface.ICalculate Calculate { get; set; }

private void ThisAddIn_Startup(object sender, System.EventArgs e)

{

DirectoryCatalog catalog =

new DirectoryCatalog(

AppDomain.CurrentDomain.BaseDirectory);

CompositionContainer container =

new CompositionContainer(catalog);

CompositionBatch batch = new CompositionBatch();

batch.AddPart(this);

container.Compose(batch);

}

internal void GetCircumference()

{

double d = (double)this.Application.ActiveCell.Value2;

this.Application.ActiveCell.get_Offset(0, 1).Value2 =

Calculate.Circumference(d);

}

As you can see, the code is almost identical to what I had in my console app. The difference here is that I split up the composition from the method invocation. I set up the catalog and CompositionContainer and perform the composition on startup, but I defer actually invoking the imported method until the user clicks my custom Ribbon button:

public partial class RibbonX : OfficeRibbon

{

public RibbonX()

{

InitializeComponent();

}

private void RibbonX_Load(object sender, RibbonUIEventArgs e)

{

}

private void buttonCircumference_Click(

object sender, RibbonControlEventArgs e)

{

Globals.ThisAddIn.GetCircumference();

}

As before, this works with either my first implementation of the contract, or the alternate version.

One obvious question that springs to mind is, “can this model be used to mitigate the versioning problem in Office?”. Specifically, for example, could you use this model to build an add-in that dynamically composes components that implement either 2003-style CommandBar UI or 2007-style Ribbon/TaskPane UI? The answer is, No, probably not in any useful way. If you think about it, at the core of the MEF model is the contract: the model relies on the contract being the ‘fixed’ point in the moving constellation of composable parts. In the CommandBar vs Ribbon scenario, the contract is not fixed – you’re either using CommandBar interfaces or you’re using Ribbon/TaskPane interfaces.

You can perhaps envisage an imaginary IOfficeUi interface, which one component might implement to render commandbars while another component implements the same interface to render ribbons – but this is an imaginary scenario, and it does not map to the reality of Office versioning. Where the Office add-in scenario does map to the MEF model is in the composability of add-ins – because all add-ins must implement IDTExtensibility2, and they can implement it in arbitrarily different ways (within some constraints). However, back to what I said at the top of the post – this is conceptually similar to the MEF model, but does not use MEF.

All right, then, you’re thinking – why can’t we devise such an IOfficeUi interface for use between our add-in and composable parts that implement this differently? Well, of course, we could do this – but not in any useful way. Imagine what you’d need to build… Because of the way Office uses the new optional extensibility interfaces (IRibbonExtensibility, ICustomTaskPaneConsumer, etc), your add-in must advertise that it either does or does not implement these interfaces very early on in its lifetime – very soon after it is loaded. If you don’t tell Office up front that you implement these interfaces, you’ll never get called back on them. So, even if you build an Office 2003 add-in (which does not use these interfaces), you’d still be obliged to implement them in case you’re actually running in Office 2007 or later.

Moreover, the imaginary IOfficeUi interface would probably end up being very generic – plus you’d have the problem of how to communicate between the UI and the business logic in your solution. You’d end up with some hopelessly generic interfaces like this:

public interface IOfficeUi

{

// In Initialize, construct CommandBars or Ribbon/TaskPane.
void Initialize(object addIn);

IBusinessLogic BusinessLogic { get; set; }

}

public interface IBusinessLogic

{

// In InvokeMethod, invoke business logic from the UI event handlers.
object InvokeMethod(string methodID, params object[] args);

IOfficeUi OfficeUi { get; set; }

}

This is not really a workable model. So, for the UI versioning case, the only really workable approach is to componentize along the lines of my post here, using the lowest-common denominator but implementing later interfaces. MEF doesn’t help you in this scenario.

MEF

andreww — Wed, 01 Apr 2009 05:18:00 GMT

The Managed Extensibility Framework (MEF) is a new library, still under development, that provides support for composing applications dynamically. Many applications have a composite model, where the total functionality is provided by a number of component parts. Often, these components are all known at design-time, so the composition is static. However, it is sometimes useful to be able to build the composition dynamically – where the set of components to be loaded is only discovered at runtime. Office client apps are composite apps in the sense that they discover and load add-ins dynamically – although of course Office apps do not use MEF. A preview of the MEF code, documentation and samples are available on codeplex here.

Let’s consider a simple example. A console app wants to invoke functionality that can be implemented in components discovered at runtime. There must be no static reference to the components within the app. To provide this indirection, the app needs to communicate with these components via an interface that they both recognize. The component implements this interface, and is then deployed in such a way that the app can discover it at runtime. Here’s the interface:

public interface ICalculate

{

double Circumference(double radius);

}

The idea of using interfaces to communicate between components that can be built independently is not new, but the MEF framework simplifies the discovery and composition mechanics. I can create a simple class library project (which I shall call “Interface”) that contains just this interface. MEF components (or “composable parts”) do not directly depend on one another, instead they depend on a contract, which is a string identifier. It is reasonable to specify a contract via an interface, to ensure separation. So, I can implement this interface in another class library (which I’ll call “Implementation”):

[Export(typeof(Interface.ICalculate))]

public class Calculate : Interface.ICalculate

{

public double Circumference(double radius)

{

return 3.14159 * radius * 2;

}

Note the use of the Export attribute. This is defined in the assembly System.ComponentModel.Composition.dll, which is released as part of the preview of the MEF library on codeplex. Effectively, this specifies that I’m exporting the type identified by the string “Interface.ICalculate”.

Finally, I can create a console application project which specifies the contract it wants to use (via the Import attribute), uses MEF to discover and compose the available components, and then invokes the implemented contract:

class Program

{

[Import]

public Interface.ICalculate Calculate { get; set; }

static void Main(string[] args)

{

Program p = new Program();

p.Run();

Console.ReadKey();

}

private void Run()

{

//AssemblyCatalog catalog =

// new AssemblyCatalog(Assembly.Load(

// "Implementation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"));

DirectoryCatalog catalog =

new DirectoryCatalog(

AppDomain.CurrentDomain.BaseDirectory);

CompositionContainer container =

new CompositionContainer(catalog);

CompositionBatch batch = new CompositionBatch();

batch.AddPart(this);

container.Compose(batch);

Console.WriteLine(

String.Format("{0}", Calculate.Circumference(4)));

}

The app uses a MEF catalog to load the assembly that implements the interface (‘exports the contract type’) that it wants to use. There are several different kinds of catalog. I’ve deliberately chosen not to use a simple AssemblyCatalog – because (as you can see from the commented code) that would require me to specify the assembly name for the assembly to be loaded – and I explicitly want to have zero knowledge of the implementing assembly (ie, no static reference) within the consuming application.

For this reason, I’m using a DirectoryCatalog, and pointing it at the folder where the executing assembly is. This means that the catalog will be able to use any assemblies it finds in this folder when it comes time to build the composition.

Next, I create a CompositionContainer, and initialize it with the DirectoryCatalog (and therefore, with all the assemblies that the DirectoryCatalog finds). I also add the current application object to the container, so that its dependencies (Import requirements) are included in the composition operation. Then, I can invoke the Compose method – this matches up all the Imports and Exports that have been collected in the container. Finally, I can invoke the contract method (“Circumference”) on the imported type, and I’m done.

So far, my composite app has been made up of 3 assemblies: the app itself, the interface assembly, and the implementation assembly. To further illustrate how MEF dynamic composition works, let’s suppose I have an alternative version of the implementation assembly (let’s call it “Alternate.dll”). You can imagine that this is produced by a different team, or perhaps bought in from a 3^rd party vendor. Instead of the simple constant value for Pi that I used in my first implementation, this alternative implementation uses Math.PI:

[Export(typeof(Interface.ICalculate))]

public class Calculate : Interface.ICalculate

{

public double Circumference(double radius)

{

return Math.PI * radius * 2;

}

Note that this is not simply an updated version of the same assembly – it is a completely independent assembly, with a different assembly name. I can simply deploy this alternate version to the same folder as the consuming application. I do NOT need to rebuild the app, because it did not have any static reference to the implementation assembly – it only referred to the interface assembly, which has not changed.

At runtime, the catalog will pick up the alternate assembly, and the CompositionContainer will compose the composite app such that the consuming app code can transparently use the new version. Note that I cannot deploy both versions of the implementation assemblies to the same location – because the DirectoryCatalog will find them both, and then the CompositionContainer will barf if it finds 2 implementations of the same Export. So, when I deploy the alternate implementation, I must be careful to remove the original one.

You can see that this mechanism would in fact also work in the case of updated versions of the same assembly – although in that scenario the ‘dynamic discovery and composition’ feature is less obviously useful, because you’re more likely to know the assembly name at design-time.

As you can see, MEF is pretty simple, yet it enables a quite powerful dynamic composition model.