The 3rd day of the SDP

The 3rd day of the SDP was over and I want to thanks all the attendants.
my yesterday session was about C# 5 async and await.

today I will have a full day tutorial on Rx and TPL Dataflow.
you can download the demo code and also the presentation for second and third days from here (the link is also having the demo code for today's sessions).

anyway, I also want to recommend 2of yesterday session.

if you were attend at the conference you should have an access to the sessions video page.
first I want to recommend Ofir Makmal's session about .NET 4.5 CLR improvements.

Ofir was talking about subjects like:

Multi-core JIT
Managed Profile Guided Optimization
Auto-Ngen
Background Server GC

my favorite subject was Multi-core JIT.

the following is a snippet for Multi-core JITing.

Code Snippet
 static void Main(string[] args)
{
    ProfileOptimization.SetProfileRoot(@"C:\MyApplicationFolder");
    ProfileOptimization.StartProfile("startup.profile");
}
 

my second recommendation is Manu Cohen-Yashar's session about .NET cryptography.
Manu's talk is great for anyone who want to use the .NET cryptography library.

Posted: May 08 2013, 12:17 AM by bnaya

תגים:SELA, Rx, Parallel, TPL, Dataflow, TDF, async, await, Reactive Extension, SDP, TPL Dataflow, TAP, cryptography, clr

Async / Await for .NET 4, Silverlight and Windows Phone

if you have to target .NET 4, Silverlight and Windows Phone and
still want to use the async / await pattern.

the BCL team provide you with a new NuGet package named Microsoft.Bcl.Async.

this package was announced as stable a few week ago.
so you can check it out if you're having VS 2012 but should target one of the above platforms.

be aware that this package won't work with 2010.

Posted: May 07 2013, 05:25 AM by bnaya

תגים:SELA, Parallel, Task, Thread, TPL, await, TAP, BCL, Parallel.Async

EF should adopt the WAQS framework

I was speaking with Matthieu MEZIL about his WAQS framework,
it is a layer of abstraction over the Entity Framework which I think you should check out.
Matthieu is working on it on his free time (currently as an open source) and it is amazing to see what he was able to achieve.
this framework is already been in used by some of real word company and it is improving over time (today Matthieu is working on a new version of it).

as I see it, Microsoft EF team should adopt this framework as part of the EF open source project. I hope that the EF team will put the effort to merge it into their source code.

WAQS is addressing many of the painful scenarios under EF, with a great design and productivity.

as I understand Matthieu is willing to let the EF team to take ownership over his labor and I believe that it is an opportunity that will be pity to waste (everything within this framework came out of Matthieu's field experience in order to ease his customer pain).

this post is a call to action, if you like this framework or the ideas it represent vote for it at:

http://data.uservoice.com/forums/72025-entity-framework-feature-suggestions/suggestions/3929780-waqs

Posted: May 07 2013, 05:08 AM by bnaya

תגים:SELA, Entity Framework, EF, ORM, SDP, Database, WAQS

SDP (day 2)

the second day of the SDP was over and I want to thanks all the attendants of my sessions.

at day 1 I was giving a full day on TPL, I was covering lot of API, tools and techniques.

the demo codes for this session can be found at http://sdrv.ms/1283vDW

the second day session was about .net 4.5 / VS 2012 new features, tolling and overloads for parallel programming.

the code sample for this session can be found at http://sdrv.ms/18NeNje

tomorrow I will talk about the new C# 5 parallel syntax (async / await) and
on Wednesday I will provide a full day on Rx (reactive Extension) and TDF (TPL Dataflow).

I general we are having a successful conference with a local and foreign speakers.

Posted: May 06 2013, 11:53 AM by bnaya

תגים:SELA, Parallel, SDP

EF 6: Async

this post is the first in a series about what's new in EF 6.

great improvements are about to come with Entity Framework 6.
it is a major release and the first one since EF become an open source.
each post in the series will be dedicate to a single feature.

this post will focus on a new EF a-sync features.

the first question that should be asked is, why do we need parallel data access?
moreover why do we need a dedicate parallel data access API, rather then using the TPL Task.Run(…) in order to introduce parallelism?

the answer is related both to thread safety and ThreadPool optimization.

a dedicate data access API for parallel programming, ensured a thread safe access, which may not be a trivial task.

furthermore, when the database is executing a query the .NET thread is idle (waiting for the execution result).
if this idle thread has taken from ThreadPool (either directly or through high level API like TPL Task.Run(…)) it could lead to a ThreadPool starvation.

assuming that you have a 2 second query, Task.Run(…) will hold the ThreadPool's thread for 2 second even though it idle while the database is executing the query.

what you really want is an API that operate over IOCP (IO completion port). IOCP API will release the ThreadPool's thread back to the pool and re-claim a thread at the completion time.

at the API level you can find a-sync operations everywhere.
I will present some of the main API.

the following snippets, will use the following entities (code first):

Code Snippet
 public class Author
{
    public Author()
    {
        Blogs = new List<Blog>();
    }
    public int Id { get; set; }
    public string Name { get; set; }
    public IList<Blog> Blogs { get; set; }
}
 
public class Blog
{
    public int Id { get; set; }
    public string Title { get; set; }
    public string Content { get; set; }
    public int AuthorId { get; set; }
 
}
 

and the following context:

Code Snippet
 public class Context : DbContext
{
    public DbSet<Author> Authors { get; set; }
    public DbSet<Blog> Blogs { get; set; }
}
 

a-sync save

Code Snippet
 using (var context = new Context())
{
    context.Authors.Add(author);
    int affected = await context.SaveChangesAsync();
}
 

notice the await at line 4.

a-sync read

Code Snippet
 using (var context = new Context())
{
    Author[] authors = await context.Authors
        .Include(a => a.Blogs)
        .ToArrayAsync();
    return authors;
}
 

line 5, is where the magic happens.

execute command

Code Snippet
 using (var context = new Context())
{
    int affected = await 
        context.Database.ExecuteSqlCommandAsync("DELETE FROM BLOGS");
}
 

summary

EF 6 is having a great parallel API, which respect IOCP and compatible with the new async / await syntax.

Posted: Mar 19 2013, 11:02 AM by bnaya

תגים:DEV, SELA, Parallel, Entity Framework, EF, Task, Thread, async, await, TAP, api, entity

Parallel and The C# Memory Model

Parallel programming can be tricky, both compiler and CPU's optimization can lead into a twilight zone's debugging.

lets take the following code snippet snippet:

Code Snippet
 class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("Start");
        var u = new Util();
        u.Exec();
        Console.ReadKey();
    }
}
 
public class Util
{
    private bool _stop = true;
    public void Exec()
    {
        Task t = Task.Run(() =>
            {
                bool b = true;
                while (_stop)
                {
                    b = !b;
                }
                Console.WriteLine("Complete {0}", b);
            });
        Thread.Sleep(30);
        _stop = false;
    }
}
 

can you predict the outcome?
will it ever reach the completion at line 24?

you can download the snippet from here.

now download the snippet and try to execute it in the following order:

Compiled in Debug mode and double click on the exe file (without an attached debugger).
Compiled in Release mode and double click on the exe file (without an attached debugger).
Compiled in Release mode and run it F5 (with an attached debugger).

so why does is execute predictably in Debug mode, while behaving quit strange in Release mode?
even stranger why does it execute predictably in Release mode when a debugger attached?

what happening is a matter of a single thread optimization that can occurs at the compiler (JIT) or CPU level which is taking assumption which is not acceptable for parallel execution.

it can be fixed up using different API like Thread.MemoryBarrier and other.

instead of explaining this out, I will offer you a reading of part 1 and part 2 of a great article on those matters.

Summary

the optimization world is still rely on a single thread assumption (with some special instruction for parallel execution).
while the computing world becoming more parallel each day, this single thread assumption priority may have to be change in the future.

in order to avoid pitfalls, you should be aware o it and use a parallel dedicated APIs.

Posted: Mar 06 2013, 01:46 AM by bnaya

תגים:DEV, SELA, Parallel, Task, Thread, TPL, TPL Dataflow, continuation, Concurrency, rase, optimization, MemoryBarrier, reordering, Memory model

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.

Posted: Feb 17 2013, 02:45 PM by bnaya

תגים:DEV, Extensibility, SELA, extension, Composition, ImportMany, Export, Import, Parallel, Task, CompositionContainer, collection, BCL, Immutable, Thread-safe

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.

Posted: Feb 16 2013, 09:05 AM by bnaya

תגים:DEV, MEF, SELA, Composition, ImportMany, Export, Import, CompositionContainer, RegistrationBuilder, Catalog

The problem of animals and foods

this is a short post that is dealing with a classic riddle.

I was thinking on this riddle when I was trying to figure out a Scala feature. we are having (at Sela Group) a small Scala study group led by Israel Tabadi and while we were going over Scala's abstract type (which is by the way a cool implementation) I was thinking about the .NET equivalent solution.

I will use the problem of "animals and foods" (taken from here) as an anchor's point.

The problem: assuming an Animal with a method, Eat, which eats some food. and the riddle is, how can you restrict a Cow (which derived from an Animal), to eat nothing but Grass (at compile time). A Cow can't eat an arbitrary food like Fish.

the idea is to restrict a Cow to a specialize type of food which is Grass.

the Scala version is available here.

now take your time and think of how can you solve it using .NET and Generics?

the solution is to assign the Cow's type to Grass (as simple as it is, sometimes it can slip away).

the solution is present on the following snippet:

Code Snippet
 public abstract class Food { }
public class Grass : Food { }
public class Club : Grass { }
public class DogFood : Food { }
 
public abstract class Animal<T> 
    where T : Food
{
    public void eat(T food)
    {
        Console.WriteLine("{0} eat {1}", this.GetType().Name, food.GetType().Name);
    }
}
 
public class Cow: Animal<Grass> 
{
}
 
public class Dog : Animal<DogFood> 
{
}
 

the following snippet is the main method part:

Code Snippet
 var dogFood = new DogFood();
var grass = new Grass();
var club = new Club();
    
var dog = new Dog();
var cow = new Cow();
    
dog.eat(dogFood);
//dog.eat(grass) // not compiled
cow.eat(grass);
cow.eat(club);    
 

and the result is:

Posted: Feb 08 2013, 11:51 AM by bnaya

תגים:DEV, SELA, .net, Generics, Type, animals and foods, Abstract, Scala

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.

Posted: Jan 24 2013, 11:31 AM by bnaya

תגים:DEV, MEF, SELA, extension, Composition, ImportMany, Export, Import, Metadata, .NET 4.5, exception, Catalog, egistrationBuilder

This Week On Channel 9

my blog was manage to get on Channel 9 week's top developer news.

Posted: Jan 16 2013, 01:59 AM by bnaya

תגים:DEV, MEF, SELA, Bnaya, net 4.5, news, ch9

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

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.

Posted: Jan 16 2013, 01:21 AM by bnaya

תגים:DEV, MEF, SELA, extension, Composition, ImportMany, Export, Import, .NET 4.5, CompositionContainer, RegistrationBuilder, Catalog

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.

Posted: Jan 15 2013, 01:04 AM by bnaya

תגים:DEV, MEF, SELA, extension, Composition, ImportMany, Export, Import, CompositionContainer, RegistrationBuilder, Catalog

Open House at Microsoft

yesterday I was lecturing at Microsoft about VS 2012, .NET 4.5, async/await, Rx and TPL Dataflow.

there was 90 people attended and I hope that everybody has learn something new.

the code sample for this lecture available here.

Posted: Jan 14 2013, 02:48 AM by bnaya

תגים:DEV, SELA, Rx, Parallel, Task, TPL, Dataflow, TDF, Reactive, async, await, Reactive Extension, TPL Dataflow, vs 2012, .net 4.

Async and AggregateException

this post is a complementary to Eran Stiller's post.

I was reading Eran Stiller's post about exception handling using async methods and I want to add a few side notes.

1) the exception handling behavior decisions is well documented in this post (by the TPL team), it decided after they had consider different options.

2) I was suggesting that compiler will check whether the a catch of AggregateException is implemented and if so to avoid the unwrapping behavior.
in this case the it can be assumed that programmer do expect multiple exceptions.
unfortunately, for the current version, I was speaking with them after the release of .NET 4.5.
I hope that we will see this mitigation in future release.

3) for the current version you can use the following work around if you do want to catch aggregate exception:

Code Snippet
 await Task.WhenAll(t1, t2)
    .ContinueWith(t => { if (t.Exception != null) throw t.Exception; });
 

by re-throwing the exception the unwrapped exception will be AggregateException.
it may be wise to wrap this pattern in an extension method because it can be a very repetitive one.

Proper Disclosure

Eran is one of my colleague and definitely one of the more talent Architect I was happened to work with.

Posted: Jan 14 2013, 01:19 AM by bnaya

תגים:DEV, SELA, Parallel, Task, TPL, async, await, TAP, C#5, exception, exception handling, .net4.5

Bnaya Eshet

Recent Posts

Tags

Navigation

Disclaimer

Archives

Async / Await for .NET 4, Silverlight and Windows Phone

EF should adopt the WAQS framework

EF 6: Async

a-sync save

a-sync read

execute command

summary

Parallel and The C# Memory Model

Summary

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)

Exception

Composition options

Summary

The problem of animals and foods

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

Summary

This Week On Channel 9

MEF 2.0 - mini series: part 6

(Composition scoping and lifetime management)

Summary

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

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

summary

Open House at Microsoft

Async and AggregateException

Proper Disclosure