Tag Archives: mef

Diagnosing MEF Composition Errors

For all its goodness, if something goes wrong, problems with MEF are terribly hard to diagnose. Thankfully, there’s an article out there by Daniel Plaisted at Microsoft that goes into great detail into all the things that can go wrong with MEF and how to get to the bottom of each one. I have it bookmarked, and if you work a lot with MEF, you should too. The one area that I find most useful, though, is figuring out composition-time errors using tracing.

With MEF, if you are using the Import attribute and there are errors during composition – either due to a bad Export, a missing DLL, or even an exception in the constructor, the composition itself will not choke. It will simply not load the Export and therefore anything that depends on it into the container. The problem then manifests itself as a missing Export when you try to use it. By then, it’s too late to know what happened.

An easy diagnosis tool from the article I mentioned above is to drop the following snippet into your application configuration file (App.config, Web.config, what-have-you).

<system.diagnostics>
  <sources>
    <source name="System.ComponentModel.Composition" switchValue="All">
      <listeners>
         <add name="fileListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="composition.log" />
      </listeners>
    </source>
  </sources>
  <trace autoflush="true" indentsize="4" />
</system.diagnostics>

After the composition routine runs, check the file configured above (in this example, “composition.log“) for any errors. You will have to sift through a lot of “everything’s okay” type messages, but errors stand out fairly easily. If something is causing the composition to skip certain parts, it will tell you exactly what and why – so you can fix it and move on rather than scratch your head and wonder what’s wrong. Make sure you disable it after you’re done though – the trace is pretty verbose and if you leave it on, that file will grow extremely large before you know it.

Advertisements

On Code Generation and Its Application to Aspect Orientation

TL;DR

The CodeDOM is a cool library within .NET that can be used for structured code generation and compilation. When combined with Reflection, one neat application is to be able to inject aspects into your code at run-time. I have created Aspects for .NET, a library that does just that, and also tries to bring AOP to MEF.

Whether it be generating boilerplate, generating proxy classes or processing DSL, code generation has numerous applications. There are a few different options for code generation in .NET:

T4: With T4 you create text templates that consist of literal text and “special” text that gets compiled, run and the output of the run inserted into the template to create the final output (a-la ASPX/Razor, etc.) If you need to generate code at design time off a model or DSL, this is your best bet. You can extend the T4 library and write stuff that does runtime code generation too. In that case though, you would be playing around with code in string literals. Not ideal.

CodeDOM: I feel that CodeDOM is a somewhat under-appreciated part of the .NET framework in that it does not get a lot of buzz (or at least that has been my impression). I am not sure what impact the introduction of Roslyn will have on it, but as of right now I love it the way it is. It is a DOM based approach to working with programmatically constructed code. The entire .NET type system is represented as different node types in the DOM. You can construct a DOM from scratch, or parse existing code into a DOM. Given a DOM, you can generate code in a given language (provided you have the code provider), or compile the DOM on-the-fly into an assembly that you can then load up and use. That is cool in my book any day.

Another cool approach is to combine the two- write classes that use CodeDOM to generate code as a string, and then use that in T4 templates. In any case, I think the choice depends on whether you want your code generated at design time or run-time.

Design Time: You would need to do this if there is non-generated code in your application that references constructs from within the generated code. The burden of having to keep generated code around in source control could be somewhat alleviated by having the generation take place as part of the build. In that case, also, however, until you build, the rest of your code is going to have a lot of squiggly red lines. Now, if the rest of your code only referenced interfaces and the implementations were generated, assuming you were using some sort of dependency injection mechanism, that would be a solution. However, that is not the norm with T4 (i.e. generating only on build).

Run-Time: With this strategy, you would generate code at run-time (most probably using CodeDOM to generate an in-memory assembly), load that up using Reflection or MEF or what-have-you and then use it. Preferably you would want this to happen at startup or very infrequently for performance reasons. In this case, also, you would need a minimal set of constructs that the rest of your code can reference that provides a bridge to the generated code. An example of this would again be non-generated interfaces with generated implementations.

As I think about it, there are two applications that I have been wanting to use run-time code generation for:

  • Generating WCF proxies when we have a reference to the service/data contracts (although increasingly I have been thinking that might be unnecessary, that’s another blog post to come).
  • Aspect oriented programming, or more accurately introducing aspects into my implementation code.

Now, aspects as a concept is quite good. To be able to remove cross-cutting stuff from your business logic code is always good. The attribute model in .NET is a very good fit for applying aspects. There are a few issues with what prevails in terms of AOP in .NET though:

  • PostSharp: They’re pretty popular within the AOP crowd, but I don’t like my code messed with post-compilation.
  • There are IoC containers that support AOP out of the box, but I don’t like to tie myself to any one container just because they support AOP; besides I have been using MEF for everything.
  • MEF does not have AOP support.
  • If you peruse through NuGet, there are quite a few AOP libraries out there. If you think about it, though, this is a perfect application for run-time code generation. I already have CodeDOM and Reflection in my toolbox. Why not build it in the spirit of rolling my own? I can then build it the way I think makes sense and build it with MEF support in mind.

To that effect, I ended up writing Aspects for .NET. It is a library that provides interfaces that you can implement to build your own aspects which you can then apply to your implementation classes. It provides a mechanism to wrap, at runtime, your implementation with aspects. There is also integrated support for MEF, albeit with some limitations.

You can visit the project page or the GitHub repo for more detailed documentation, but to summarize, you can “wrap” a class with aspects at run-time. When you do so, it inspects the contract interface and implementation class using reflection. It uses CodeDOM to generate an on-the-fly implementation of the contract interface, which expects an instance of the implementation to be initialized, and where each member simply calls out to the implementation (i.e. a hollow wrapper). However, in the process, it also inspects the implementation member to see if any aspect attributes are applied and adds code at appropriate places before or after the invocation to execute those aspects. The type that is generated on the fly is cached in memory.

As with everything else, there is always room for improvement and feedback is welcome.

Handling Duplicate Libraries with MEF

While building the composition/DI piece for the Commons Library, one problem I ran into was the fact that if you told MEF to load assemblies from a number of different places – and they all had copies of the same library (which is possible especially with common dependencies), MEF would load the exports in each assembly as many times as it finds it. What you end up with then is a whole bunch of matching exports for a contract that you expect only one of.

One easy way to handle this is to assume that FullName for an assembly truly uniquely identifies it (i.e. the code within two instances of an assembly with the same FullName should not be different). We can then do something like the following (assume here that modulesDirectories is anIEnumerable<string> that consists of the list of directories we want to load our assemblies from).

In the above snippet, we use a class AssemblyEqualityComparer, which can be defined as follows:

You can find the full Commons Library code implementation for this here.

MEF for everything!

In the first of a series of blogs around my Commons Library, I want to shed more light on my choice of MEF as the underlying mechanism for the AK.Commons.Composition namespace – which handles dependency injection as well as extensibility or plugin type stuff. I like its attribute based syntax, choice of different types of catalogs and dynamic discovery (and yes, I am not using dynamic discovery just yet but I intend to; the same goes for taking advantage of different types of catalogs). The following three features, however, stood out for me:

  • The fact that you can support multiple cardinalities – i.e. you can ask for one implementation of something, or many.
  • Metadata attributes – which you can use decorate your exports with additional metadata. This combines well with multiple cardinalities. I can have multiple providers that implement a single contract. I can then choose the ones I want based on their metadata properties. This is more of an extensibility thing than a DI thing – but you can also use this to introduce versioning into your DI mechanism. You could have multiple versions of something available and the consumer could ask for a specific version (or some predicate around the version). That can lend itself well to setting up a continuous deployment environment.
  • Lazy imports – oh how I love lazy imports. This lets you define imports that are resolved when the containing class is composed, but the actual value is not computed until it is needed for the first time. That gets me out of circular dependency hell with ease (and I know we should strive to structure things so that there aren’t circular dependencies to begin with, but at times it is unavoidable).

One other factor is that MEF is part of the framework as opposed to being a third party library, and that Microsoft is behind it. That means one less third party dependency to deal with if you wanted to use AK.Commons. I already have this cool extensibility mechanism that is part of the framework, and it does what I need for DI. Why not use it for DI as well? I have heard the whole “MEF is not for DI” debate quite a bit. It has worked well for me so far though.

One thing I miss in MEF is support for AOP. I do intend to do something about that pretty soon though!