Development In a Tesseract

I’ve recently been looking at better ways to combine IoC functionality with MEF composition.  I’ve created a workable solution using just MEF but there is some nasty boilerplate floating around when creating nested containers.

As an example to this issue, the data model contains a set of nested objects in which the Root object holds the MEF CompositionContainer and uses that container to satisfy imports on objects it creates.  At some point in the heirarchy, an object representing a context needs to add new features to a container to be used only in children of the context holding object. Currently, I’m using the code below to establish the nested container, but unfortunately, it is tying my code heavily to MEF through the direct use of the container and Import attributes.

  [Import]
  private CompositionContainer CompositionContainer { get; set; }
  
  private void OnImportsSatisfied()
  {
    // we replace the imported container with a new one in which we are adding 
    // context specific services.
    CompositionContainer = new CompositionContainer(CompositionContainer);
      
    var additionalStuff = new AdditionalStuff();
    var batch = new CompositionBatch();
    batch.AddExportedValue(additionalStuff);
    
    // Items deeper in the context chain are going to import this container
    batch.AddExportedValue(CompositionContainer);
    
    CompositionContainer.Compose(batch);
  }

As a starting point for decoupling this code, I’ve looked into the autofac library which with the version 2 experimental version has some MEF integration support.

The example Nicholas Blumhardt uses the Lazy<T> capabilities of .NET 4, but doesn’t really show the integration with MEF using the Catalog registration services.

By making some modifications to the code in his example, you can really show how the MEF components can be pulled into the autofac container very easily.

the first step is to connect the MEF export attributes to the meta data used by the logger imports.

    public interface ILogAppenderMetadata
    {
        string AppenderName { get; }
    }

    [MetadataAttribute]
    [AttributeUsage(AttributeTargets.Class)]
    public class LogAppenderAttribute : ExportAttribute, ILogAppenderMetadata
    {
        public LogAppenderAttribute() : base(typeof(ILogAppender))
        {
        }

        public string AppenderName { get; set; }
    }

The creation of this attribute will simplify the tagging of exports using the ILogAppender contract. The next step is to apply the new attribute to the logger implementations.

 [LogAppender(AppenderName="printer")]
 public class PrinterLogAppender : ILogAppender
  {
  ...
  }
  
  [LogAppender(AppenderName="screen")]
  public class ScreenLogAppender : ILogAppender
  {
  ...
  }

Finally, the Main method is modified to make use of the catalog registration services provided by autofac.

  static void Main(string[] args)
  {
    var builder = new ContainerBuilder();
    var catalog = new TypeCatalog(typeof (PrinterLogAppender), typeof (ScreenLogAppender));
    builder.RegisterComposablePartCatalog(catalog);
  
    builder.RegisterType<Program>();
    builder.RegisterType<Log>();
  
    using (var container = builder.Build())
    {
        container.Resolve<Program>().Run();
    }
  }

When the program is run, the container correctly picks up the MEF exports without any further reference to imports and exports.  What I need now is to understand a better way to create the nested containers using the autofac library rather than pure MEF.

I've been working in organizations that adhere to some level of the CMMI for some time now.  And we are trying to fit what we can of agile programming into our process, and hopefully are achieving better results while still keeping the structure required of our contracts.

A long time ago I ran across this article which discusses some of the levels of process that are often encountered in the wild, but rarely discussed by SEI.

So here's the The Capability Im-Maturity Model (CIMM) as envisioned by Capt. Tom Shorsch USAF.

I have started looking at improvements to the NMock2 code with respect to writing a branch of the code in .NET 3.5.

The availability of extension methods in C# 3.0 have solved a common code issue of mine where I want to use Dictionary.TryGetValue to see if there is a value in a dictionary for a given key and create a default if not.  Which leads to the following code.

public static class ExtensionMethods
{
    public static U SafeGetValue<T,U>(this Dictionary<T,U> dictionary, T key)
      where U:new()
    {
        U value;
        if (!dictionary.TryGetValue(key, out value))
        {
            dictionary[key] = value = new U();
        }
        return value;
    }

    public delegate U NewInstance<U>();

    public static U SafeGetValue<T, U>(this Dictionary<T, U> dictionary, T key, NewInstance<U> newInstance)
    {
        U value;
        if (!dictionary.TryGetValue(key, out value))
        {
            dictionary[key] = value = newInstance();
        }
        return value;
    }
}

I'm currently involved in getting mono to compile on Solaris 9, Solaris 2.5 and DEC Tru64 Unix.  I'll be posting more about my experiences with this.  Hopefully I can get it to work, because the projects I'm working on would be much better done in a cross-platform managed environment than having to worry about the details of C++ compatibility.  If anyone has any experience here, I'd appreciate pointers.