Bnaya Eshet : Composition

Immutable Collections

bnaya — Sun, 17 Feb 2013 19:45:12 GMT

Immutable Collections

Immutability is a pattern which is suit well parallel programming,
but you have to be aware of a potential memory pressure risk when it's not implemented right or used wisely.

this post will cover a new BCL library (still in its preview stage) which is targeting immutable collections.

.NET is already having Concurrent implementation for Queue, Stack, Bug and Dictionary, which is thread-safe, but other type of collection like List is missing.
another type of collection are read only collection, but those type of collection are not truly thread-safe because it is just a wrapper upon other collection which can be mutate by it's owner.
so iterating on a read only collection doesn't guarantee thread-safety because the collection can be mutate during the iteration by it's original owner.
currently we do have one option to create an immutable collection by using the ToArray() extension method, but as I mentioned before it can lead to a memory pressure while using a large collection.

the BCL team was targeting this issue and are working on a new kind of collections which are immutable.
those collection is having a cool concept which guarantee that an immutable sequence will not changed, but it can be part of another immutable sequence. this mean that you can take an immutable collection and add an item. this will keep the immutable part as is and you will get a new collection that include your addition and the original collection, but if someone is using the original collection he won't be affected by your mutation.
as you can see the BCL immutable collection can be mutate but the mutation will return a new collection and leave the original collection untouched.

Start using the immutable collection

you can start using it though NuGet.
on the current preview version it includes:

ImmutableStack<T>
ImmutableQueue<T>
ImmutableList<T>
ImmutableHashSet<T>
ImmutableSortedSet<T>
ImmutableDictionary<K, V>
ImmutableSortedDictionary<K, V>

Fluent API

I will speak about 3 APIs:

Add
AddRange
Builder

Add

Code Snippet
 [Test]
public void List_AddItem_Test()
{
    var col = ImmutableList<int>.Empty;
    var col1 = col.Add(1);
    var col2 = col1.Add(2);
 
    Assert.AreEqual(0, col.Count);
    Assert.AreEqual(1, col1.Count);
    Assert.AreEqual(2, col2.Count);
}
 

whenever you want an empty instance of immutable collection you should use the static Empty property (there is no public constructor available).

you should always remember that Adding an item will not affect the original collection therefore you must handle the return value (is is the same concept as string.Replace).

finally you can notice at lines 8-10 that the above code was actually construct 3 different immutable collections.

AddRange

both from performance and usability it is better using the AddRange API when you intend to add multiple items.

Code Snippet
 [Test]
public void List_AddRange_Test()
{
    var col = ImmutableList<int>.Empty;
    var col1 = col.AddRange(Enumerable.Range(0, 1000));
 
    Assert.AreEqual(0, col.Count);
    Assert.AreEqual(1000, col1.Count);
}
 

Builder

if you want to efficiently add multiple items and AddRange doesn't do the job for you, you can use a Builder (the concept is quit similar to StringBuilder).
you should remember that unlike the immutable collection a builder is not a thread-safe structure, therefore you shouldn't share its state between threads.
when you complete the mutation, you can extract an immutable collection from the builder.

Code Snippet
 [Test]
public void List_Builder_Test()
{
    var col = Enumerable.Range(0, 1000).ToImmutableList();
    var builder = col.ToBuilder();
    for (int i = 0; i < 100; i++)
    {
        builder.Remove(i * 10);
    }
    var col1 = builder.ToImmutable();
    Assert.AreEqual(1000, col.Count);
    Assert.AreEqual(900, col1.Count);
}
 

line 5: getting a builder from immutable collection.
line 10: getting an immutable back from the builder (after the mutation).

Migration

if you are using a read only collection though the IReadOnlyCollection, IReadOnlyList or IReadOnlyDictionary, migration will be easy because the immutable collections are implementing those interfaces.

Optimization

we already spoke about the memory pressure optimization, but what is the characterize of those collection in compare with the well known BCL mutable collection?
as the BCL team argue that immutable collections have been heavily tuned for maximum performance and minimum GC pressure.

the following table was published by the BCL team.
it compare the performance behavior of the BCL immutable and immutable collection (and remember that this is only a preview version which mean that further optimization can be applied).

you can read more on this at this post.

summary

Immutability is a great pattern for parallelism.
the BCL team are giving us a robust and well design immutable collection.
the potential memory pressure has reduced by the internal data-structure design.
so it is definitely something to wait for its release.

you can read more about it at here.
and if you want more background and comparison to the read only collection, you can check out this post.

MEF 2.0 - mini series: part 8 (Composition options and exception handling)

bnaya — Sat, 16 Feb 2013 14:05:57 GMT

MEF 2.0 - mini series: part 8 (Composition options and exception handling)

this is the last post in the MEF 2.0 mini series.
you can see other posts of this series in here.

this post will wrap-up the series with a quick survey to to the to some changes made for the underline composition process.

Exception

one of the most painful experience of MEF 1 was its misleading exception's description. some time it was really hard to figure out the exception roots. you can read more about MEF 1 issues in here.

MEF 2 was doing a much better job, but still some composition failure are misleading.
my recommendation is to use the IPartImportsSatisfiedNotification which can give you an interception point where you can figure out what went wrong, before MEF is throwing a composition exception.

the pattern that I'm using is to allow default on any imports and validate it on the OnImportsSatisfied method, see the next snippet:

Code Snippet
 public class Foo : IPartImportsSatisfiedNotification
{
    [Import(AllowDefault=true)]
    public IIdentity Identity { get; private set; }
 
    [ImportMany]
    public IReflect[] Reflects { get; private set; }
 
    public void OnImportsSatisfied()
    {
        if (Identity == null)
        {
            Trace.WriteLine("Composition failure (Identity)");
            throw new ArgumentNullException("Identity");
        }
 
        if (Reflects == null || Reflects.Length == 0)
        {
            Trace.WriteLine("Composition failure (Reflects)");
            throw new ArgumentNullException("Reflects");
        }
    }
}
 

Composition options

MEF 2 is exposing some composition tuning options that wasn't available on MEF 1.
there was some hidden composition assumptions which you couldn't modified.
I will focus on the DisableSilentRejection options.
silent rejection was added into MEF composition in order to support robust composition of ill functioning plug-ins. the requirement for this feature came from the Visual Studio team which is using MEF for their plug-in model.
anyway you might want to alter this behavior. MEF 2 doe's let you the option to disable it.
the original behavior will exclude the ill functioning plug-in from the composition (for import many) without throwing an exception.
this led to scenarios when you had a real hard time to figure out why some of the plug-in wasn't loading and still everything seem to be working.

the following snippet is demonstrating this scenario:

Code Snippet
 class Program
{
    static void Main(string[] args)
    {
        var p = new Program();
 
        var cat = new AssemblyCatalog(Assembly.GetExecutingAssembly());
        var container = new CompositionContainer(cat, CompositionOptions.DisableSilentRejection);
 
        try
        {
            container.ComposeParts(p);
            Console.WriteLine("{0} Plug-ins loaded", p.Plugins.Length);
        }
        catch (CompositionException)
        {
            Console.WriteLine("Composition error");
        }
    }
 
    [ImportMany]
    public Iplugin[] Plugins { get; set; }
}
 
[InheritedExport]
public interface Iplugin { }
 
public class BadPlugin : Iplugin
{
    [Import(typeof(IIdentity))]
    public IIdentity MissingDependency { get; set; }
}
 
public class FinePlugin : Iplugin { }
 

line 8: disabling the silent rejection behavior.
line 28 - 32: a class that is having a missing dependencies, therefore cannot be construct. on silent rejection mode (which is the default) it will be simply removed from the composition and the Plugins property at line 22 will get a single plug-in rather then 2.

Summary

MEF 2 is having improvements both in the engine and the API level.
you do have more control over the composition and better descriptive exception.

MEF 2.0 - mini series: Part 7 (Catalog filter and Deep hierarchic scoping)

bnaya — Thu, 24 Jan 2013 16:31:18 GMT

MEF 2.0 - mini series: Part 7 (Catalog filter and Deep hierarchic scoping)

this is the 7th post in the MEF 2.0 mini series.
you can see the following TOC for other posts in this series.

in the previous post I was talking about composition scoping and lifetime management.
on this one, I will extend the composition scoping topic toward hierarchic along with catalog filtering capability.

hierarchic scoping is not trivial, you must understand the hierarchic behavior and what it was design for.

MEF hierarchic was design to enable parts from higher scope to access lower scope's part without re-instantiation, lower part do not target higher scope's part directly.

each hierarchic scope construct by importing a ExportFactory<T> (which we saw in the previous post).

I will try to make it as simple as I can.

the following diagram demonstrate the idea of sub scope that interact with its parent scope's items.

let try to have a similar code structures.

I will use a plug-in base class to trace the instantiations:

Code Snippet
 public abstract class PluginBase
{
    private static int _globalId = 0;
    protected int _id;
 
    public PluginBase()
    {
        _id = _globalId++; // not thread-safe
    }
}
 

derived class's ids will be incremented per instantiation.

the following snippet include the classes which will be used for our hierarchic demonstration:

Code Snippet
 public class Level1ScopeRoot : PluginBase
{
    [Import]
    public Level1ItemA ItemA { get; private set; }
    [Import]
    public Level1ItemB ItemB { get; private set; }
}
 
public class Level1ItemShared : PluginBase { }
 
public class Level1ItemA : PluginBase
{
    [Import]
    public Level1ItemShared ItemZ { get; private set; }
}
 
public class Level1ItemB : PluginBase
{
    [Import]
    public Level1ItemShared SharedItem { get; private set; }
 
    [Import]
    public ExportFactory<Level2SubScopeRoot> SubScope { get; private set; }
}
 
public class Level2SubScopeRoot : PluginBase
{
    [Import]
    public Level2SubItem1 SubItem1 { get; private set; }
 
    [Import]
    public Level2SubItem2 SubItem2 { get; private set; }
}
 
public class Level2SubItem1 : PluginBase
{
    [Import]
    public Level1ItemShared ItemShared { get; private set; }
    [Import]
    public Level2SubItemShared SubItemShared { get; private set; }
}
 
public class Level2SubItem2 : PluginBase
{
    [Import]
    public Level2SubItemShared SubItem { get; private set; }
}
 
public class Level2SubItemShared : PluginBase { }
 

all the classes prefixed with the scoping 'Level'.

referring a sub-scope required using of ExportFactory<T> (line 23).

the following diagram is showing their hierarchic and dependencies graph:

our final step is to define a catalog per scope's hierarchic and to set hierarchic structure.

Code Snippet
 var picker = new RegistrationBuilder();
picker.ForTypesDerivedFrom<PluginBase>()
    // add ScopeLevel metadata 
    .AddMetadata("ScopeLevel", t => t.Name.StartsWith("Level1") ? 1 : 2)
    .Export<PluginBase>();
 
var catalog = new AssemblyCatalog(typeof(Program).Assembly, picker);
 
var catalogL0 = catalog.Filter(p => p.ContainsPartMetadata("ScopeLevel", 1));
var catalogL1 = catalog.Filter(p => p.ContainsPartMetadata("ScopeLevel", 2));
 
var scopeL1 = new CompositionScopeDefinition(catalogL1, null);
var scopeL0 = new CompositionScopeDefinition(catalogL0, new[] { scopeL1 });
 
var container = new CompositionContainer(scopeL0);
 

at line 2-5, I export everything inherits from 'PluginBase' and adding a 'ScopeLevel' metadata with the right scope leveling value.

line 7, define a general assembly catalog (which will be the base for the filtered catalogs).

lines 9,10, are defining a filtered catalog for each scoping level (filtering an existing assembly catalog).

lines 12,13, defines the hierarchic between the scoped catalogs.

line 15, create a container with the top level scope.

now we're ready for a composition.

here you can download a sample code.

Summary

I consider this feature as MEF 2's most complex one.

Hierarchic can become complex, so use it with caution.

MEF 2.0 - mini series: part 6 (Composition scoping and lifetime management)

bnaya — Wed, 16 Jan 2013 06:21:01 GMT

MEF 2.0 - mini series: part 6

(Composition scoping and lifetime management)

this is the 6th post in the MEF 2.0 mini series.
you can see the following TOC for other posts in this series.

in this post I will cover a new concept of scoping and part lifetime management, which is a great improvement over MEF 1.

MEF 1 was coming with a fairly naïve lifetime management.
part's lifetime could be either shared or non-shared (you could also apply 'any' but eventually 'any' will be created as shared or non-shared).
shared is a singleton instantiation, while non-shared will create a new instance each time.

MEF 1's instantiation model doesn't support a complex scenario where some dependency's lifetime should be dictate by the lifetime of other unites.
you can conceder a UI window that is having plug-ins that should be dispose while the UI window is closing.

for example consider you have the following components (parts) dependency flow:

the application can have multiple processes.
each process is having some plugins, but each view should have different instantiation of the plugins.
until now you can argue that a non-shared instantiation will do the job.
the next dependency level (DAL) should be shared under the boundary of a process but shouldn't be shared across processes.
this one can neither handle by the share nor by non-shared instantiation.
single instance of DAL should be created under each view scope.

MEF 2 added a scoped lifetime management.
I will use the attribute based model for this sample, but it will work in the same way in the fluent model.

Code Snippet
 [Export]
public class Application
{
    [Import]
    private ExportFactory<ProcessA> ProcAFactory { get; set;}
    [Import]
    private ExportFactory<ProcessB> ProcBFactory { get; set;}
}
 
[Export]
public class ProcessA 
{
    [Import]
    public PluginA PlugA { get; private set; }
    [Import]
    public PluginB PlugB { get; private set; }
}
 
[Export]
public class ProcessB 
{
    [Import]
    public PluginA PlugA { get; private set; }
    [Import]
    public PluginB PlugB { get; private set; }
}
 
[Export]
public class PluginA 
{
    [Import]
    public DAL Dal { get; private set; }
}
 
[Export]
public class PluginB
{
    [Import]
    public DAL Dal { get; private set; }
}
 
[Export]
public class DAL
{
}
 

at line 4-7 you can see a new type of importing target called ExportFactory<T> this type will initialize the scope.
It is having a CreateExport method that return a ExportLifetimeContext<T> can control the part life time.

the full implementation of the Application class is:

Code Snippet
   [Export]
  public class Application
  {
      [Import]
      private ExportFactory<ProcessA> ProcAFactory { get; set;}
      [Import]
      private ExportFactory<ProcessB> ProcBFactory { get; set;}
 
      public void WriteLayoutA()
      {
          using (ExportLifetimeContext<ProcessA> lifeOfA = ProcAFactory.CreateExport())
          {
              ProcessA a = lifeOfA.Value;
              Console.WriteLine("Proc A");
              Console.WriteLine("\tPlug A: {0}", a.PlugA.GetHashCode());
              Console.WriteLine("\t\tDal: {0}", a.PlugA.Dal.GetHashCode());
              Console.WriteLine("\tPlug B: {0}", a.PlugB.GetHashCode());
              Console.WriteLine("\t\tDal: {0}", a.PlugB.Dal.GetHashCode());
          }
      }
 
      public void WriteLayoutB()
      {
          using (ExportLifetimeContext<ProcessB> lifeOfB = ProcBFactory.CreateExport())
          {
                ProcessBb = lifeOfB.Value;
              Console.WriteLine("Proc B");
              Console.WriteLine("\tPlug A: {0}", b.PlugA.GetHashCode());
              Console.WriteLine("\t\tDal: {0}", b.PlugA.Dal.GetHashCode());
              Console.WriteLine("\tPlug B: {0}", b.PlugB.GetHashCode());
              Console.WriteLine("\t\tDal: {0}", b.PlugB.Dal.GetHashCode());
          }
      }
  }
 

you can see the usage of ExportFactory<T> at lines 11 and 24.

having a lifetime handled part is the first step for the scoping.
now we can define which part will be managed by the scope.
for each scope we except to find a single instantiation of each scoped part.
as you can see in the diagram below, the Plugins and the DAL should be instantiate once for each scope.

in order to define what's goes within the scope we should use the CompositionScopeDefinition as shown in the following code snippet:

Code Snippet
 static void Main(string[] args)
{
    var scopeDependentCatalog = new TypeCatalog(
        typeof(ProcessA),
        typeof(ProcessB), 
        typeof(PluginA),
        typeof(PluginB),
        typeof(DAL));
    var scopeDefDependent = new CompositionScopeDefinition(scopeDependentCatalog, null);
 
    var appCatalog = new TypeCatalog(typeof(Application));
    var scopeDefRoot = new CompositionScopeDefinition(appCatalog, new[] { scopeDefDependent });
 
 
    var container = new CompositionContainer(scopeDefRoot);
 
    var app = container.GetExportedValue<Application>();
 
    app.WriteLayoutA();
    Console.WriteLine("------------------------------------");
    app.WriteLayoutB();
}
 

you can see the scope dependent definition at line 9
and the hierarchic between the scope and the application at line 12.

as you may notice it is possible to have deeper hierarchic, but this will be shown in future posts.

the output is:

remember that we was printing the part's hash code.
you can easily see that each process is having different plugin and DAL's instantiations, but even those the DAL was consumed by both plugins it has a single instantiation per scope.

Summary

scoping is a very powerful instantiation model which can solve some of the real-life scenario which wasn't fall into the shared or non-shared models.

in future post I will present a deeper hierarchic and the catalog filtering capability.

MEF 2.0 - mini series: part 5 (Fluent export properties)

bnaya — Tue, 15 Jan 2013 06:04:54 GMT

MEF 2.0 - mini series: part 5 (Fluent export properties)

this is the 5th post in the MEF 2.0 mini series.
you can see the following TOC for other posts in this series.

in this post I will cover the fluent property's export.

Exporting properties is a less known feature of MEF.
MEF 1 was supporting this feature by using the attribute model.
you could decorate a property with a [Export] attribute and then it become available for imports.

the following code demonstrate property exporting in MEF 1:

the Foo class is importing multiple SymmetricAlgorithm:

Code Snippet
 [Export]
public class Foo
{
    [ImportMany]
    public SymmetricAlgorithm[] CryptoProviders { get; private set; }
}
 

and the CryptoComposer class is exporting a few symmetric algorithms:

Code Snippet
 [Export]
public class CryptoComposer
{
    [Export]
    public SymmetricAlgorithm Aes { get { return new AesManaged(); } }
    [Export]
    public SymmetricAlgorithm TripleDES { get { return new TripleDESCryptoServiceProvider(); } }
    [Export]
    public SymmetricAlgorithm RC2 { get { return new RC2CryptoServiceProvider(); } }
}
 

with the following composition the Foo instance will have the CryptoComposer's symmetric algorithms:

Code Snippet
 var catalog = new AssemblyCatalog(typeof(Program).Assembly);
var container = new CompositionContainer(catalog);
 
var foo = container.GetExportedValue<Foo>();
 

so, how do we do it with the fluent export API?

to keep it simple I will leave the Foo class with the attribute model (we learned how to use fluent import in the previous post):

Code Snippet
 [Export]
public class Foo
{
    [ImportMany]
    public SymmetricAlgorithm[] CryptoProviders { get; private set; }
}
 
public class CryptoComposer
{
    public SymmetricAlgorithm Aes { get { return new AesManaged(); } }
    public SymmetricAlgorithm TripleDES { get { return new TripleDESCryptoServiceProvider(); } }
    public SymmetricAlgorithm RC2 { get { return new RC2CryptoServiceProvider(); } }
}
 

in order to export the CryptoComposer's properties you should use the following code:

Code Snippet
 var picker = new RegistrationBuilder();
picker.ForType<CryptoComposer>()
    .ExportProperties(p => p.PropertyType == typeof(SymmetricAlgorithm));
 
var catalog = new AssemblyCatalog(typeof(Program).Assembly, picker);
var container = new CompositionContainer(catalog);
 
var foo = container.GetExportedValue<Foo>();
 

summary

exporting properties using the fluent API is fairly straightforward.

MEF 2.0 - mini series: part 4 (Fluent Import)

bnaya — Sat, 12 Jan 2013 05:18:51 GMT

MEF 2.0 - mini series: part 4 (Fluent Import)

this is the 4th post in the MEF 2.0 mini series.
you can see the following TOC for other posts in this series.

in this post I will discuss the Fluent import API.

we was talking about Fluent Export and Constructor Injection in the previous posts. this post will complete the main scenarios of Import's fluent API.

I will demonstrate the import technique using the following classes:

Code Snippet
 public class Foo
{
    public Logger Log { get; set; }
}
 
public class Logger
{
    public void Write(string message) { /* ... */ }
}
 

we can Export both classes by one of the fluent techniques which we discuss in previous posts, for example:

Code Snippet
 var picker = new RegistrationBuilder();
picker.ForType<Logger>()
    .Export<Logger>();
picker.ForType<Foo>()
    .Export();
 
var catalog = new AssemblyCatalog(typeof(Foo).Assembly, picker);
var container = new CompositionContainer(catalog);
 

but this is not enough, because Foo's Log property has no [Import] attribute, therefore it will be ignored by the composition.

using the fluent ImportProperties, you can introduce it into the composition :

Code Snippet
 picker.ForType<Foo>()
    .Export()
    .ImportProperties<Logger>(pi => pi.Name == "Log");
 

the property's Type is referred by the generics parameter while the Lambda used for filtering the target properties.

actually you can take it further and configure the import behaviors.
for example you can set the import to Allow Default:

Code Snippet
 picker.ForType<Foo>()
    .Export()
    .ImportProperties<Logger>(pi => pi.Name == "Log",
                (propInfo, builder) => builder.AllowDefault());
 

it's consider as best practice to Allow Default and implement IPartImportsSatisfiedNotification interface which is an interception point which occurs right after the composition.
the idea is to check the composition state within the OnImportsSatisfied()
method in order to verify the composition state.
It is true that MEF exceptions have made better, but it still not perfect and sometimes it is really hard to trace the root cause of the exception. implementation of IPartImportsSatisfiedNotification will make the tracing easier.

so what about Select Many?

let change our Foo class to the following code:

Code Snippet
 public class Foo: IPartImportsSatisfiedNotification
{
    public Logger[] Log { get; set; }
 
    public void OnImportsSatisfied()
    {
    }
}
 

the following code will define the Log property as [ImportMany]:

Code Snippet
 picker.ForType<Foo>()
    .Export()
    .ImportProperties<Logger>(pi => pi.Name == "Log",
                (propInfo, builder) => builder.AsMany());
 

as you can see we are using the same overload that can manipulate the Import's behaviors.

by the same technique you can define a re-composition and the creation policy:

Code Snippet
 picker.ForType<Foo>()
    .Export()
    .ImportProperties<Logger>(pi => pi.Name == "Log",
                (propInfo, builder) =>
                {
                    builder.AsMany();
                    builder.AllowRecomposition();
                    builder.RequiredCreationPolicy(CreationPolicy.NonShared);
                });
 

summary

fluent Import is complimentary to fluent Export.
it's fairly flexible API which enable to assign your own or 3rd party class's properties.

actually you can take a 3rd party class and inject it's public properties through those techniques.

MEF 2.0 - mini series: part 3 (Fluent import constructor)

bnaya — Wed, 09 Jan 2013 21:09:10 GMT

MEF 2.0 - mini series: part 3 (Fluent import constructor)

this is the 3rd post in the MEF 2.0 mini series.
you can see the following TOC for other posts in this series.

in this post I will discuss the fluent constructor injection API.

Constructor Injection

the following code is having a Logger and Worker class which is having 2 constructor (one has no parameters and the other is getting ILogger):

Code Snippet
  
public class Logger: ILogger
{
    public void Write(string message) { /* ... */}
}
 
public class Worker
{
    private ILogger _logger;
 
    public Worker()
    {
        /* ... */
    }
 
    public Worker(ILogger logger)
    {
        _logger = logger;
    } 
}
 

the question is, which of the construction will be invoked by the following code?

Code Snippet
 var picker = new RegistrationBuilder();
picker.ForTypesDerivedFrom<ILogger>()
    .Export<ILogger>();
picker.ForType<Worker>()
    .Export();
 
var catalog = new AssemblyCatalog(typeof(Program).Assembly, picker);
var container = new CompositionContainer(catalog);
container.Compose(new CompositionBatch());
var w = container.GetExportedValue<Worker>();
 

the code Export the Logger and the Worker but doesn't define explicitly which of the Worker's construction should be invoke.

the answer is that it will invoke the constructor that is getting the ILogger parameter, but could we be more precise?

actually we do have 2 different options.

first option is to use SelectConstructor before the Export method.
see the following code:

Code Snippet
 var picker = new RegistrationBuilder();
picker.ForTypesDerivedFrom<ILogger>()
    .Export<ILogger>();
picker.ForType<Worker>()
    .SelectConstructor(builder => new Worker(builder.Import<ILogger>()))
    .Export();
 
var catalog = new AssemblyCatalog(typeof(Program).Assembly, picker);
var container = new CompositionContainer(catalog);
container.Compose(new CompositionBatch());
var w = container.GetExportedValue<Worker>();
 

this way we can define an expression that define which constructor should be invoke.
the expression is getting a ParameterImportBuilder which I used to define the logger (builder.Import<ILogger>()).

the next option is to set the SelectConstructor after the Export.
now we are getting a ConstructorInfo[] and we can select a single constructor out of this array.
ConstructorInfo

Code Snippet
 var picker = new RegistrationBuilder();
picker.ForTypesDerivedFrom<ILogger>().Export<ILogger>();
picker.ForType<Worker>()
    .Export()
    .SelectConstructor(ctors => 
        ctors.First(info => info.GetParameters().Length == 1));
 

the code select a constructor which is having a single parameter, but the real implementation is up to you. you can ask on whatever constructor's aspect which you like to.

Summary

as cool as it is to control the constructor injection using the fluent API,
you may consider to use imported properties rather than constructor injection because it can be more stable is during the composition state and can apply on more scenarios, including implementation of IPartImportsSatisfiedNotification.

MEF 2.0 TOC

bnaya — Sun, 06 Jan 2013 14:30:49 GMT

MEF 2.0 TOC

MEF 2.0 is a reflection of a community requests.
features like Open Generics, fluent and conventional discovery, lifetime handling of the part, better exception handling and more, was all requested by the community.

you can read more about MEF 1 series:

SDP - MEF (Real-Life patterns)

bnaya — Fri, 18 Mar 2011 13:36:51 GMT

SDP - MEF (Real-Life patterns)

On the last day of the SDP at Crown Plaza Hotel, Tel Aviv.

I was lecturing about Real-Life scenario of MEF failures.

the lecture was focusing on diagnostic ,solutions and testing.

I want to thanks all attendant's, It was the after lunch session and

you were bravely kept your eyes open.

the presentation pdf can be found here.

you can use the following check-list as recommended diagnostic process.

Diagnostic Check-List

Is the instance included in the composition
Are the plug-in assemblies included in the deployment path
Are the plug-in dependencies included in the probing path
Is the Silverlight XAP included in the application
Use Strong Name and versioning policy
Do not refer to imported properties during construction time, use IPartImportsSatisfiedNotification
Check that IEnumerable<T>’s are decorated with [ImportMany] as long as they come from multiple exports.
Remember that errors in nested dependencies are sometimes obscured
Use AllowDefault=true when nulls are permitted
Use ComposeExportedValue for including mocks of your dependencies

Exporting non Exportable types

bnaya — Sat, 30 Oct 2010 19:23:56 GMT

Exporting non Exportable types

this post extend Glenn Block's post about

"Poco, Mef, and custom type systems. Are you ready to take the red pill?"

the post is adding a compile time attribute export model, Directory catalog

and migrate Glenn code to VS 2010.

It is very recommended to read Glenn Block's post before reading

this one.

the code sample for this post can be download from here.

Summarizing Glenn's post

in general Glenn show how to add attributes (like Export) to 3rd party type

which doesn't support it (it is cool technique which doesn't related directly to MEF).

Glenn show how to write catalog which can be aware of types extension.

What was added?

I took Glenn's source, fix it to run against the CLR 4.0,

then I added a directory catalog which aware of the

type extension and I also add a nice clean way of exposing the type

by using assembly level attribute.

the directory catalog is very straight forward so I wont cover it in the post

(you can download the source and see the implementation).

the following code show how to use the assembly level attribute:

Code Snippet
 [assembly: ComposablePartRegistry(typeof(MyNoneExportedType), typeof(IMyNoneExportedType))]
 

as you can see, all you have to do is to declare the exported type followed by the exported contract.

the attribute snippet:

Code Snippet
 [AttributeUsage (AttributeTargets.Assembly)]
public class ComposablePartRegistryAttribute : Attribute
{
    public ComposablePartRegistryAttribute(
        Type implementation, Type contract, 
        CreationPolicy policy = CreationPolicy.Any)
    { 
        Type t = typeof (ComposablePartType<,>);
        t = t.MakeGenericType(new[] {implementation, contract});
        Type = Activator.CreateInstance(t, policy) as TypeDelegator;
    }
 
    public TypeDelegator Type { get; private set; }
}
 

line 8-10: creating ComposablePartType type which later be used by the catalog.

Summary

this was small extension to Glenn's concept which can be very useful

in cases where you want to embrace 3rs party component into your MEF model.

Testing and Debugging MEF, avoiding misconceptions - Part 3

bnaya — Fri, 29 Oct 2010 13:34:32 GMT

Testing and Debugging MEF, avoiding misconceptions - Part 3

this is the 3rd post of this series and it will

discuss common misconceptions which may lead unexpected behavior and long

debugging nights.

Initialization issues

the first misconception occurs when developer are trying to access

imported property at construction time.

NullReferenceException
 [Export]
public class MyPlugin
{
    public MyPlugin()
    {   // the logger import doesn't satisfied yet 
        // the next line will result with NullReferenceException
        Logger.Write("MyPlugin initialized");
    }
 
    [Import]
    public ILogger Logger { get; set; }
}
 

MyPlugin instantiation occur when the MEF container composed,

the composition process will create an instance and only then it will try

to satisfy its imports. which mean that at the construction time the imports does not yet satisfied.

the above code will result with NullReferenceException.

What can we do about it?

we can have a few solutions solving this issue:

we can use ImportingConstructor (but we should use it carefully because
cross import constructor may lead to deadlock and rejection).

ImportingConstructor
 [Export]
public class MyPlugin
{
    // cross import constructor can lead to deadlock an rejection
    [ImportingConstructor] 
    public MyPlugin(ILogger logger)
    {  
        logger.Write("MyPlugin initialized");
    }
}
 

this way the logger will be instantiate before the instantiation of MyPlugin.

we can implement IPartImportsSatisfiedNotification (which is my favorite technique because there is no dead lock risk).
this way we can initialize our component right after all imports has been satisfied.

IPartImportsSatisfiedNotificat
 [Export]
public class MyPlugin: IPartImportsSatisfiedNotification 
{
    public void OnImportsSatisfied()
    {
        // happens just after the imports satisfaction
        Logger.Write("MyPlugin initialized");
    }
 
    [Import]
    public ILogger Logger { get; set; }
}
 

MEF infrastructure will call OnImportsSatisfied right after it done with the composition process.

None composed instance issue

developers are used to instantiate their own type using the new keyword (var plugin = new MyPlugin()).

doing so wouldn't satisfy any of the imported properties (because the type doesn't took part in any composition), because MEF does not aware of the instantiation.

How can we do it right?

we can introduce the instance to the composition by using ComposePart.
the compose part will satisfy any of the instance imports.

ComposeParts
 [TestMethod]
public void GetInstanceFromContainerTest()
{
    var catalog = new AssemblyCatalog(typeof(ILogger).Assembly);
    var container = new CompositionContainer(catalog);
 
    var plugin = new MyPlugin(); ;
    container.ComposeParts(plugin);
 
    Assert.IsNotNull(plugin.Logger);
}
 
public interface ILogger
{
    void Write(string content);
}
 
[Export(typeof(ILogger))]
public class MyLogger:ILogger
{
    public void Write(string content)
    {
        Debug.WriteLine(content);
    }
}
 
[Export]
public class MyPlugin 
{
    [Import]
    public ILogger Logger { get; set; }
}
 

other solution is getting our instance dynamically from
the container (for example by using GetExportedValue)

GetExportedValue
 [TestMethod]
public void GetInstanceFromContainerTest()
{
    var catalog = new AssemblyCatalog(typeof(ILogger).Assembly);
    var container = new CompositionContainer(catalog);
    container.Compose(new CompositionBatch());
 
    MyPlugin plugin = container.GetExportedValue<MyPlugin>();
 
    Assert.IsNotNull(plugin);
    Assert.IsNotNull(plugin.Logger);
}
 
public interface ILogger
{
    void Write(string content);
}
 
[Export(typeof(ILogger))]
public class MyLogger:ILogger
{
    public void Write(string content)
    {
        Debug.WriteLine(content);
    }
}
 
[Export]
public class MyPlugin 
{
    [Import]
    public ILogger Logger { get; set; }
}
 

using Silverlight we can initialize our container
by using CompositionHost.Initialize(catalog). and we can add the
following line to the constructor:
CompositionInitializer.SatisfyImports(this), which mean that
each time we are creating new instance it will try to satisfy it's own imports.
(be aware that you must use CompositionHost.Initialize(catalog) before using
CompositionInitializer.SatisfyImports(this))

SatisfyImports
 public class MyPlugin
{
    public MyPlugin()
    {
        CompositionInitializer.SatisfyImports(this);
    }
 
    [Import]
    public ILogger Logger { get; set; }
}
 

if you want to use the same technique for none Silverlight components,

you can download the code for System.ComponentModel.Composition.Initialization.dll

which hold CompositionHost.Initialize and CompositionInitializer.SatisfyImports

from here.

Exporting the wrong type issue

last issue is to avoid exporting or importing the wrong type.

MEF does not goes through the inheritance list,

MEF contract are explicit and doesn't aware of the inheritance chain.

the following code snippet export the MyLogger (not the ILogger).

Code Snippet
 [Export]
public class MyLogger:ILogger {
    ...
}
 

it is equivalent to:

Code Snippet
 [Export(typeof(MyLogger))]
public class MyLogger:ILogger {
    ...
}
 

while what you may really wanted is:

Code Snippet
 [Export(typeof(ILogger))]
public class MyLogger:ILogger {
    ...
}
 

the following import won't get the first 2 snippet because of the explicit contract comparison:

Code Snippet
 [Import]
public ILogger Logger { get; set; }
 

Summary

MEF instantiation occurs at runtime and sometime it is not

so easy or straight forward for debug.

avoiding common misconceptions may save us long debugging hours.

I strongly recommend the following post which discuss other points of failure:

Testing and Debugging MEF, Tips - Part 2

bnaya — Wed, 13 Oct 2010 00:41:04 GMT

Testing and Debugging MEF, Tips - Part 2

this is the second post of a series that will offer some tips

about testing and debugging your MEF-able component and application.

in this post we will focus about debugging the most common, and most confusing,

MEF failure.

Assembly Loading Failure

the most common MEF runtime failure occurs because of missing assembly

which contain the MEF parts (Import, Export) or

the parts dependencies (like 3rd party components).

under the hood MEF is using reflection, which mean that MEF loading

behavior is similar to the reflection dynamic loading.

Tracing Loading Failure?

I will suggest 2 option for tracing the failure:

1. we can register to assembly resolve event (AppDomain.CurrentDomain.AssemblyResolve)

Code Snippet
 AppDomain.CurrentDomain.AssemblyResolve += OnAssemblyResolveHandler;
static Assembly OnAssemblyResolveHandler(object sender, ResolveEventArgs args)
{
    Logger.WriteLine("Assembly Resolve: " + args.Name);
 
    return args.RequestingAssembly;
}
 

the problem with that approach is that we may get some smoke events which

actually succeed (because of the .NET probing).

2. catching ReflectionTypeLoadException exception

Code Snippet
 try
{
    container.ComposeParts(p);
}
catch (ReflectionTypeLoadException ex)
{
    foreach (Exception exc in ex.LoaderExceptions)
    {
        Logger.WriteLine(exc.Message);
    }
}
 

we can wrap the composition using try catch scope.

and catch ReflectionTypeLoadException. this will

give us pretty good idea what's got wrong.

Summary

my suggestion is whenever possible, wrapping any composition and catch the ReflectionTypeLoadException, in other cases we can use the first technique.

Credits

Ohad Schneider should have credit for part of the code in this post.

Testing and Debugging MEF, Tips - Part 1

bnaya — Fri, 09 Jul 2010 22:32:17 GMT

Testing and Debugging MEF, Tips - Part 1

this is the first post of a series that will offer some tips

about testing and debugging your MEF-able component and application.

in this post we will focus about exporting Mock objects.

the code sample for this post can be download from here.

Prerequisite

if you are not familiar with Mocks you better read more about this subject before

proceeding with this post (in short Mocks are fake object which is use for separate

dependencies during unit testing).

the sample is using the Moq library as it mocking infrastructure.

Having the following code:

1. contract

Contract
 public interface ILogger
{
    void Write(string message);
}
 

2.exported contract implementation

Export (contract implementor)
 [Export (typeof(ILogger))]
public class DebugLogger: ILogger
{
    public void Write(string message)
    {
        Debug.WriteLine(message);
    }
}
 

line1: export the class as ILogger

3. contract consumer

Import (contract consumer)
 public class MyLogic
{
    [ImportMany]
    private IEnumerable<ILogger> Loggers { get; set; }
 
    public void DoYourThings()
    {
        foreach (ILogger logger in Loggers)
        {
            logger.Write("Some log");
        }
 
        Console.WriteLine("Done");
    }
}
 

line 3: import any available loggers

4. composition and execution

Main
 class Program
{
    static void Main(string[] args)
    {
        var logic = new MyLogic();
        var cat = new AssemblyCatalog(typeof(Program).Assembly);
        var container = new CompositionContainer(cat);
        container.ComposeParts(logic);
 
        logic.DoYourThings();
        logic.DoYourThings();
 
        Console.ReadKey();
    }
}
 

How can we write unit test for the DoYourThings method?

MEF dependencies is already loosely coupled by it nature, but in order to

validate the method behavior we still need to check whether the the method

do write logs.

we will inject a Mock<ILogger> into the MEF container in order to validate

this behavior.

the following code snippet is showing how:

Test
 [TestMethod]
public void TestMethod1()
{
    // Arrange
    var logic = new MyLogic();
    var container = new CompositionContainer();
    var loggerMock = new Mock<ILogger>();
    container.ComposeExportedValue<ILogger>(loggerMock.Object);
    container.ComposeParts(logic);
 
    // Test
    logic.DoYourThings();
 
    // Validate
    loggerMock.Verify(logger => logger.Write(It.IsAny<string>()), Times.Once());
}
 

line 7: creating mock object.

line 8: inject the mock object into the container.

Summary

using the ComposeExportedValue method, we can inject

mock object into our CompositionContainer, therefore at the composition stage

the Import properties will get our mock objects.

MEF for Beginner (Deployment Catalog) - part 12

bnaya — Fri, 02 Apr 2010 01:20:55 GMT

MEF for Beginner (Deployment Catalog) - part 12

this is the 12th post of the MEF for Beginner series, the series TOC is available here.

this post will focus on Deployment Catalog.

the code sample for this post can be found here.

What is MEF Deployment Catalogs?

the deployment catalog is actually a redesign of the older package catalog.

it enable to load parts from xap packages a-synchronically.

Code sample

the following code sample depend on 2 assembly that should be added to the project:

System.ComponentModel.Composition
System.ComponentModel.Composition.Initialization

at the startup (app.xaml)

Code Snippet
 private void Application_Startup(object sender,StartupEventArgs e)
{
    InitializeContainer();
    this.RootVisual = new MainPage();
}
 
private void InitializeContainer()
{
    var catalogs = new AggregateCatalog();
 
    var catalog = new TypeCatalog(typeof(PlugIns));
    catalogs.Catalogs.Add(catalog);
 
    // Create deployment catalog
    var deployCatalog = new DeploymentCatalog("PlugIns.xap");
    deployCatalog.DownloadCompleted += OnDownloadCompletedHandler;
    deployCatalog.DownloadProgressChanged += OnDownloadProgressChangedHandler;
    deployCatalog.DownloadAsync();
 
    catalogs.Catalogs.Add(deployCatalog);
 
    // initialize the main application composition host (container)
    CompositionHost.Initialize(catalogs);
}
 

line 3, initialize MEF before the creation of any windows that depend on MEF.

line 9, define aggregate catalog (this is basically a catalog collection).

lines 11-12, create type catalog for plug-ins within the main xap (plug-in within the main xap

can be assess directly) and add the catalog to the aggregate catalog.

line 15, create deployment catalog (it get the xap relative path as parameter).

lines 16-17, register for xap download process events (optional).

line 18, start downloading the xap.

line 20, add the deployment catalog to the aggregate catalog.

line 23, initialize the composition host with the aggregate catalog (so

latter using CompositionInitializer.SatisfyImports will operate against the aggregate catalog).

at the MainPage.xaml the code will look as follow:

Code Snippet
 public partial class MainPage:UserControl,INotifyPropertyChanged
{
    public MainPage()
    {
        InitializeComponent();
        this.DataContext = this;
        CompositionInitializer.SatisfyImports(this);
    }
 
    private IEnumerable<string> _plugIns;
    [ImportMany(AllowRecomposition = true)]
    public IEnumerable<string> PlugIns
    {
        get
        {
            return _plugIns;
        }
        set
        {
            _plugIns = value;
            if(PropertyChanged != null)
                PropertyChanged(this,new PropertyChangedEventArgs("PlugIns"));
        }
    }
 
    public event PropertyChangedEventHandler PropertyChanged;
}
 

line 7, asking MEF to satisfy any import of the current instance (in our case the PlugIns property).

lines 11, decorate the PlugIns property for being assigned by the MEF composition.

notice that the decoration define AllowRecomposition = true, this is very important

because the deployment catalog is a-synchronic, therefore we do not control the exact time of the assignment.

Summary

deployment catalog is the current way for delay composition from xap packages.

it is a-synchronic and it will notify the catalog upon the download completion.

the code sample for this post can be found here.

Learn more

MEF for Beginner (Import from Xaml) - part 11

bnaya — Sat, 20 Mar 2010 21:28:23 GMT

MEF for Beginner (Import from Xaml) - part 11

this is the 11th post of the MEF for Beginner series, the series TOC is available here.

this post will focus on Importing mef parts directly from the Xaml.

the code sample for this post is available here.

assuming that we have the following exports:

Code Snippet
 class DemoStrings
{
    [Export("MyTag")]
    public string Text1 { get { return "Hello world"; } }
    [Export("MyTag")]
    public string Text2 { get { return "export using custom attribute"; } }
    [Export("NotMyTag")]
    public string Text3 { get { return "not included (Not My Tag contract)"; } }
    [Export("MyTag")]
    public string Text4 { get { return "Wpf markup extension"; } }
    [Export]
    public string Text5 { get { return "not included (have no contract)"; } }
}
 

we may want to have it import into the Xaml as follow:

Code Snippet
 <Window x:Class="Bnaya.Samples.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:mef="clr-namespace:Bnaya.Samples"
        Title="MainWindow" Height="350" Width="525">
    <Grid>
        <ListBox
                 DataContext="{mef:ImportManyStrings MyTag}" 
                 ItemsSource="{Binding}"/>
    </Grid>
</Window>
 

as you can see at line 8 the data context is using special definition for importing all exported strings that
define the their contract as MyTag (looking at the exports it will import the exports at lines 4,6,10).

what should we have in order to achieve that functionality?

actually very little, all we have to do is to define a markup extension that return the exported parts.

the following code is how the markup extension should be define:

Code Snippet
 [MarkupExtensionReturnType(typeof(IEnumerable<string>))]
public class ImportManyStringsExtension : MarkupExtension
{
    private readonly IEnumerable<string> _dataSource;
    public ImportManyStringsExtension(string contract)
    {
        _dataSource = CompositionHost.Provider.GetExportedValues<string>(contract);
    }
 
    public override object ProvideValue(IServiceProvider serviceProvider)
    {
        return _dataSource;
    }   
}
 

line 1, decorate that our markup extension for returning IEnumerable<string>.

line 2, derive from MarkupExtension.

line 7, at the construction time, dynamically ask mef for any discoverable parts that follow the contract.

the CompositionHost is a very small helper class that was taken from the MEF Silverlight implementation

with some very minor enhancements.

lines 10-13, returning the discoverable parts to the Xaml.

One last thing

we should remove the StartupUri from the App.Xaml and using the OnStartup override instead:

Code Snippet
 protected override void OnStartup(StartupEventArgs e)
{
    base.OnStartup(e);
 
    if (!Utils.IsInDesignTool)
    {
        var asmCatalog = new AssemblyCatalog(typeof(App).Assembly);
        var catalogs = new AggregateCatalog(asmCatalog);
        var container = new CompositionContainer(catalogs);
        CompositionHost.Initialize(container);
        container.Compose(new CompositionBatch());
        
        var root = new MainWindow(); 
        root.ShowDialog();
    }
}
 

line 5, preventing MEF operation during design time.

lines 7-9, setting the MEF container.

line 10, setting the MEF container as the main container of the application

(this way it can be reachable anywhere).

line 11, do the composition,

IMPOERANT: the composition should happens before the window instantiation,

because that when the markup extension will be invoke.

the exported part should be available at this time.

lines 13-14, starting the application.

Summary

we can extend the Xaml very easily in order to get better Xaml->Mef experience.

the code sample for this post is available here.

תגים של Technorati:‏ Import,ImportMany,MEF,composition,CLR 4

Bnaya Eshet : Composition

Immutable Collections

Immutable Collections

Start using the immutable collection

Fluent API

Add

AddRange

Builder

Migration

Optimization

summary

MEF 2.0 - mini series: part 8 (Composition options and exception handling)

MEF 2.0 - mini series: part 8 (Composition options and exception handling)

Exception

Composition options

Summary

MEF 2.0 - mini series: Part 7 (Catalog filter and Deep hierarchic scoping)

MEF 2.0 - mini series: Part 7 (Catalog filter and Deep hierarchic scoping)

Summary

MEF 2.0 - mini series: part 6 (Composition scoping and lifetime management)

MEF 2.0 - mini series: part 6

(Composition scoping and lifetime management)

Summary

MEF 2.0 - mini series: part 5 (Fluent export properties)

MEF 2.0 - mini series: part 5 (Fluent export properties)

so, how do we do it with the fluent export API?

summary

MEF 2.0 - mini series: part 4 (Fluent Import)

MEF 2.0 - mini series: part 4 (Fluent Import)

so what about Select Many?

summary

MEF 2.0 - mini series: part 3 (Fluent import constructor)

MEF 2.0 - mini series: part 3 (Fluent import constructor)

Constructor Injection

Summary

MEF 2.0 TOC

MEF 2.0 TOC

SDP - MEF (Real-Life patterns)

SDP - MEF (Real-Life patterns)

Diagnostic Check-List

Exporting non Exportable types

Exporting non Exportable types

Summarizing Glenn's post

What was added?

Summary

Testing and Debugging MEF, avoiding misconceptions - Part 3

Testing and Debugging MEF, avoiding misconceptions - Part 3

Initialization issues

What can we do about it?

None composed instance issue

How can we do it right?

Exporting the wrong type issue

Summary

Read more

Testing and Debugging MEF, Tips - Part 2

Testing and Debugging MEF, Tips - Part 2

Assembly Loading Failure

Tracing Loading Failure?

Summary

Credits

Testing and Debugging MEF, Tips - Part 1

Testing and Debugging MEF, Tips - Part 1

Prerequisite

Having the following code:

How can we write unit test for the DoYourThings method?

the following code snippet is showing how:

Summary

MEF for Beginner (Deployment Catalog) - part 12

MEF for Beginner (Deployment Catalog) - part 12

What is MEF Deployment Catalogs?

Code sample

Summary

Learn more

MEF for Beginner (Import from Xaml) - part 11

MEF for Beginner (Import from Xaml) - part 11

what should we have in order to achieve that functionality?

One last thing

Summary