C# Dev Center

Visual Studio 2010 Training Course on Channel 9

Jason Olson — Wed, 21 Oct 2009 17:08:58 GMT

This morning, Channel 9 launched the new Channel 9 Learning Center. From Channel 9, here’s a description of what the Learning Center is: “The Channel 9 Learning Center is the destination for free technical training on emerging Microsoft products and technologies. The Learning Center consists of a set of courses with each course including a set of videos, hands-on labs, and source code samples to get you up-to-speed quickly.”

I’m pleased to say that Visual Studio 2010 is one of the first Training Courses that we have launched on Channel 9. Please welcome the Visual Studio 2010 Training Course.

What is the Visual Studio 2010 Training Course? The Visual Studio 2010 and .NET Framework 4 Training Course includes videos and hands-on-labs designed to help you learn how to utilize the Visual Studio 2010 features and a variety of framework technologies including: C# 4.0, Visual Basic 10, F#, Parallel Computing Platform, WCF, WF, WPF, ASP.NET AJAX 4.0, ASP.NET MVC Dynamic Data.

Essentially, the Training Course is an online version of our Visual Studio 2010 Training Kit. In this first release of the training course, it contains a subset of the content that is actually present in the training kit. Of course, since it is an online delivery mechanism, we will continue to add more items from the training kit into this training course over the coming weeks and months.

This first version of the Training Course includes intro videos and labs on the following technology areas: managed languages, ASP.NET 4, data platform (ADO.NET and “Velocity”), WCF, WF, and Parallel Computing.

I hope you all enjoy the Visual Studio 2010 Training Course on Channel 9!

Visual Studio 2010 Beta 2 Training Kit Published

Jason Olson — Tue, 20 Oct 2009 17:54:02 GMT

The Beta 2 version of DPE’s Visual Studio 2010 Training Kit is now live (you can find it at http://tinyurl.com/Beta2Training).

A training kit includes presentations, hands-on labs, and demos. This content is designed to help you learn how to utilize a variety of Visual Studio 2010 and .NET Framework 4 technologies.

The Beta 2 release of the Training Kit contains 15 presentations, 19 hands-on labs, and 13 demos. Many technologies are covered in this release, including: C# 4, VB 10, F#, Parallel Extensions, Windows Communication Foundation, Windows Workflow, Windows Presentation Foundation, ASP.NET 4, Entity Framework, ADO.NET Data Services, Managed Extensibility Framework, and Visual Studio Ultimate.

There’s a lot of content covered here. See for yourself:

Presentations

What’s New in .NET Framework 4
What’s New in Visual Studio 2010
Introduction to ASP.NET MVC
Introduction to Managed Extensibility Framework
Introduction to .NET RIA Services
Introduction to “Velocity”
Parallel Computing for Managed Developers
Web Deployment with Visual Studio 2010
What’s New in ASP.NET AJAX 4
What’s New in ASP.NET Web Forms 4
What’s New in C# and VB
What’s New in ADO.NET Data Services
What’s New in Entity Framework 4
What’s New in Windows Presentation Foundation 4
What’s New in Windows Workflow 4

Hands-On Labs

Introduction to ADO.NET Data Services

Exercise 1: Creating and Consuming ADO.NET Data Services
Exercise 2: Consuming ADO.NET Data Services using ASP.NET AJAX
Exercise 3: Extending Data Services with Service Operations and Interceptors
Exercise 4: Adding Client-Side Paging with Row Count

ASP.NET AJAX 4

Exercise 1: Leveraging a Client-Side Template
Exercise 2: Using the DataView Control
Exercise 3: Creating Custom Markup Extensions
Exercise 4: Declaratively Instantiating Behaviors

Creating Plan My Night – ASP.NET MVC Application

Exercise 1: Creating an ASP.NET MVC Application, Plan My Night
Exercise 2: Creating Entity Framework Data Model
Exercise 3: Adding AJAX For Searching Activities

Enhancing Plan My Night – ASP.NET MVC Application

Exercise 1: Adding Caching using “Velocity”
Exercise 2: Structuring an Application using MVC Areas

Introduction to ASP.NET Web Forms 4

Exercise 1: Controlling Server Control ClientIds
Exercise 2: Enabling Bi-Directional Routing Support
Exercise 3: Granular ViewState

Microsoft Office Programmability in C# and Visual Basic
Introduction to F#

Exercise 1: Types in F#
Exercise 2: Using the Let keyword
Exercise 3: Functions
Exercise 4: Lists
Exercise 5: Pattern Matching and Recursion
Exercise 6: Types and Discriminated Unions

Introduction to the Managed Extensibility Framework

Exercise 1: Using MEF To Dynamically Add Modules to an Application
Exercise 2: Dynamically extending a form

Introduction to “Velocity”

Exercise 1: Setting up and running “Velocity”
Exercise 2: Programming directly against “Velocity” as a generic object cache
Exercise 3: Using Velocity’s SessionState provider with ASP.NET
Exercise 4 (Optional): Configure “Velocity” Cache in a cluster

Introduction to Workflow 4

Exercise 1: Hello Workflow
Exercise 2: Refactoring Workflows
Exercise 3: The CodeActivity
Exercise 4: Dynamic Workflows with XAML
Exercise 5: Testing Workflows
Exercise 6: WorkflowApplication
Exercise 7: Adding If/Else Logic
Exercise 8: Error Handling
Exercise 9: Activity Designers
Exercise 10: Hosted Designer

Introduction to Parallel Extensions

Exercise 1: Parallelize existing algorithm using static Parallel helper class
Exercise 2: Create and run parallelized Tasks
Exercise 3: Using the Task<T> class to create and run tasks that return a value
Exercise 4: Parallelizing LINQ queries using PLINQ

Test-Driven Development in Visual Studio 2010
WCF Service Discovery

Exercise 1: Ad-Hoc Discovery
Exercise 2: Metadata Extensions
Exercise 3: Announcements
Exercise 4: Discovery Proxy
Exercise 5: Legacy Discovery

Web Development in Visual Studio 2010

Exercise 1: Using HTML Code Snippets
Exercise 2: Web.config Transformations
Exercise 3: Packaging and Deploying Web Applications
Exercise 4: Packaging and Deploying Web Applications for IIS

Building a Data-Driven Master/Detail Business Form using WPF 4
Multi-touch Gesture – MFC
Multi-touch WMTouch – MFC
Ribbon – MFC
Taskbar - MFC

Demos

ContosoAutomotive (Parallel Extensions + MEF + WPF)
AdventureWorks AJAX
ASP.NET AJAX Ten-In-One
Managed Languages Ten-In-One
Barrier
CountdownEvent
Hello Visual Studio 2010
Introduction to the Managed Extensibility Framework
Parallel Baby Names
Parallel For Loop
Parallel LINQ (PLINQ)
Parallel Tasks
“Velocity”

Enjoy!

10-4 Episode 26: Creating Extensible Apps with MEF

Jason Olson — Tue, 14 Jul 2009 04:17:58 GMT

In this episode of 10-4, we take a look at a new library in .NET Framework 4 and how it helps developers write applications that are more extensible and easier to maintain than before.

For more information on the Managed Extensibility Framework, make sure to check out its home on Codeplex: http://www.codeplex.com/mef.

For more 10-4 episodes, be sure to visit:
http://channel9.msdn.com/shows/10-4

10-4! Over and out!

An Intro to Barrier, cont.d

Jason Olson — Tue, 24 Feb 2009 22:42:04 GMT

Well, I said I was going to be moving on to CountdownEvent, but I was wrong. there is one more aspect of using Barrier that I just had to share (thanks go to Stephen Toub on the Parallel Computing Platform team for bringing this up).

In my first Barrier post, I had mentioned:

Barrier is a great new synchronization primitive to use when there is a known amount of work to do that is being done by different workers that all have common synchronization points.

To make a long story short, this isn’t strictly true. Barrier can be used just fine when there is an unknown amount of work. The distinction between Barrier and other synchronization primitives isn’t about “known amount versus unknown amount of work”, it’s more about “usable once versus usable many times.” To explain this in more detail, let’s look back at the example from the last post (a Road Trip to Seattle).

Multiple Usages

First, it is perfectly allowed to use a Barrier more than once. Using the Road Trip metaphor, instead of going straight to Seattle after leaving the Gas Station, let’s have everybody stop for lunch on there way. So now there are two “sync points” that we have. First, we’ll wait for everybody to meet up at the gas station, then we’ll also wait for everybody to meet up for lunch after they’ve left the gas station.

Revising our DriveToSeattle method from the last post, we will simply call SignalAndWait() a second time to provide a second sync point where everybody meets for lunch:

static void DriveToSeattle(string name, TimeSpan timeDelay)
{
    // Perform some work
    Console.WriteLine("[{0}] Leaving House", name);
    Thread.Sleep(timeDelay);
    Console.WriteLine("[{0}] Arrived at Gas Station", name);

    // Need to wait for others
    sync.SignalAndWait();

    // Perform some work
    Console.WriteLine("[{0}] Leaving for Seattle", name);
    Thread.Sleep(timeDelay);
    Console.WriteLine("[{0}] Meet for lunch", name);

    // Need to wait for others
    sync.SignalAndWait();

    Console.WriteLine("[{0}] Leaving for Seattle", name);
}

In real-word usage of the Barrier primitive, this doesn’t have to be limited to two uses of the Barrier. We can use the Barrier any number of times we need to in order to provide these common synchronization points for our parallel code.

Unknown Number of Workers

I mentioned that it wasn’t strictly true that Barrier is great for a just a known amount of work. That’s because Barrier provides the functionality you need to even use it when the number of workers performing our work is unknown.

Back to our Road Trip. Dennis’s sister Dee is planning to come along on the Road Trip as well. However, she forgets to set her alarm and wakes up late. And unfortunately, Charlie, Mac, and Dennis have already left for Seattle. She still wants to go though so she plans to meet up with them for lunch.

What we need is for a way for Dee to flag “Hey guys! I’m coming!” And it just so happens that the Barrier class provides an AddParticipant method that we can use to make sure the extra “worker” (Dee in this case) is included the next time everybody waits for each other to “complete their work.”

In this case, Dee would simply “add herself” to the Barrier when her thread is spun up. To do this, let’s create a new DriveStraightToLunch method that will be used instead of the existing DriveToSeattle method we created before.

static void DriveStraightToLunch(string name, TimeSpan timeDelay)
{
    // "I'm coming along guys"
    sync.AddParticipant();

    // Meet for lunch
    Console.WriteLine("[{0}] Leaving for Seattle", name);
    Thread.Sleep(timeDelay);
    Console.WriteLine("[{0}] Meeting for lunch", name);

    // Need to wait for others
    sync.SignalAndWait();

    Console.WriteLine("[{0}] Leaving for Seattle", name);
}

And then we just spin up this new piece of work (added to our code in Main before all threads are joined):

... creation and start of Dennis thread

Thread.Sleep(TimeSpan.FromSeconds(6));
var dee = new Thread(() => DriveStraightToLunch("Dee", TimeSpan.FromSeconds(5)));
dee.Start();

dee.Join();
... join other threads

It’s that simple.

In Closing

I hope in the last two posts you’ve seen how useful the new Barrier synchronization primitive can be when writing Parallel Code. API-wise there really isn’t much to the new Barrier class. Of course, as is usual with writing parallel code, it’s learning to use it correctly or use it in the right situations that’s the tricky part :).

I would say "tune in next time when we chat about CountdownEvent” but considering this recent change of plans, I’m not going to tempt fate :). Later!

An Intro to Barrier

Jason Olson — Tue, 10 Feb 2009 11:17:39 GMT

In this first stage of our Tour de BCL, we will be passing through the new Barrier class.

So what is a Barrier? Let’s take a look at the ~~boring~~ technical description for a Barrier:

A Barrier is a synchronization primitive that enforces the stopping of execution between a number of threads or processes at a given point and prevents further execution until all threads or processors have reached the given point.

I don’t know about you, but sometimes technical descriptions like the above just sound like “blah, blah, blah” to me. What does a Barrier really mean to me, as a developer. Let’s break it down a different way by looking at a specific real-life scenario.

Think of a Road Trip

Instead of looking at the technical description above, think of the concept of a road trip.

There are three friends, Mac, Charlie, and Dennis. They live in a small town south of Seattle but want to take a road trip up to Seattle. So Mac calls up Charlie and Dennis and says “Hey guys, let’s take a road trip to Seattle. Meet up at the local gas station and then we’ll all leave from there.” So now they all now they need to go to the local gas station, wait for all of them to show up, and then they’ll leave for Seattle together and follow each other there.

Relating this scenario to some code, let’s say that Charlie, Mac, and Dennis are all individual threads that have one method of execution, the DriveToSeattle() method. Within that method, they are all going “to drive” to the same gas station and then continue to drive to Seattle.

If we don’t use the Barrier to synchronize the work (aka wait for each other to arrive at the gas station), each one of them will leave for Seattle the second they arrive at the gas station:

static void Main(string[] args)
{
    var charlie = new Thread(() => {
        DriveToSeattle("Charlie", TimeSpan.FromSeconds(1))
    }); 
    charlie.Start();

    var mac = new Thread(() => {
        DriveToSeattle("Mac", TimeSpan.FromSeconds(2))
    }); 
    mac.Start();

    var dennis = new Thread(() => {
        DriveToSeattle("Dennis", TimeSpan.FromSeconds(3))
    }); 
    dennis.Start();

    charlie.Join();
    mac.Join();
    dennis.Join();

    Console.ReadKey();
}

static void DriveToSeattle(string name, TimeSpan timeToGasStation)
{
    // Drive to gas station
    Console.WriteLine("[{0}] Leaving House", name);
    Thread.Sleep(timeToGasStation);
    Console.WriteLine("[{0}] Arrived at Gas Station", name);

    // Need to sync here

    // Perform some more work
    Console.WriteLine("[{0}] Leaving for Seattle", name);
}

Well, that’s hardly a road trip. If I were in Mac’s or Charlie’s shoes when Dennis left for Seattle without me, I know I would be a little upset. We obviously don’t want that to happen. So we can use the new Barrier to make sure they all “wait up” for each other at the gas station.

Using the new Barrier class

So how do you use the new Barrier class? It’s actually quite simple.The cool thing is that there are really only three things you need to learn to use the Barrier for this simple type of scenario: a single constructor and two method calls (both of which take zero parameters). Yes, it’s that simple to use.

Let’s look at what our new code using Barrier looks like (the three bold lines are the new ones):

static Barrier sync;

static void Main(string[] args)
{
    sync = new Barrier(participantCount:3);

    var charlie = new Thread(() => {
        DriveToSeattle("Charlie", TimeSpan.FromSeconds(1))
    }); 
    charlie.Start();

    var mac = new Thread(() => {
        DriveToSeattle("Mac", TimeSpan.FromSeconds(2))
    }); 
    mac.Start();

    var dennis = new Thread(() => {
        DriveToSeattle("Dennis", TimeSpan.FromSeconds(3))
    }); 
    dennis.Start();

    charlie.Join();
    mac.Join();
    dennis.Join();

    Console.ReadKey();
}

static void DriveToSeattle(string name, TimeSpan timeToGasStation)
{
    // Drive to gas station
    Console.WriteLine("[{0}] Leaving House", name);
    Thread.Sleep(timeToGasStation);
    Console.WriteLine("[{0}] Arrived at Gas Station", name);

    // Need to sync here
    sync.SignalAndWait();

    // Perform some more work
    Console.WriteLine("[{0}] Leaving for Seattle", name);
}

You can see now that nobody leaves for Seattle until everybody has arrived at the gas station. Essentially, with every call to SignalAndWait(), the number of signals received by the barrier is incremented. Once the number of signals received reaches the number of participants the Barrier was constructed with, all threads are then allowed to continue execution. And that’s all it takes to leverage the new Barrier class being introduced into the BCL with .NET Framework 4.0.

But Jason... What is up with that line of code: “sync = new Barrier(participantCount:3);”? I mean, what the heck is “participantCount:3”? How is that valid syntax?

Well, that’s easy. This is a new feature in C# 4.0 called Named Parameters where you can actually use a parameter’s name to specify what a value applies to. This becomes very handy in two places: 1) when combined with Optional Parameters, and 2) when used to clarify “magic numbers” (or “magic strings”, “magic booleans”, etc.) without having to introducing a temporary variable.

In this case, I could have left out participantCount and written just “sync = new Barrier(3);”. But I personally don’t like a magic number like “3” just floating around like this and Named Parameters give me an easy way to provide more context about the value “3”.

In Closing

So let’s look back at that ~~boring~~ technical description again:

A Barrier is a synchronization primitive that enforces the stopping of execution between a number of threads or processes at a given point and prevents further execution until all threads or processors have reached the given point.

Think about it this way:

“stopping of execution between a number of threads...” = waiting for each other to arrive
“… at a given point” = the gas station
“prevents further execution until all threads… have reached the given point” = can’t leave for Seattle until everybody shows up

See? Nice and simple!

Barrier is a great new synchronization primitive to use when there is a known amount of work to do that is being done by different workers that all have common synchronization points. However, if the amount of work needing to be done is not well known beforehand, Barrier is not the greatest primitive to use. Next we’ll look at another new synchronization primitive coming in .NET Framework 4.0 that is great to use when the amount of work is not known: the CountdownEvent.

I hope you all enjoyed this first stage in our Tour de BCL. Until the next stage, we’ll see you later.

On the potential abuse of the var keyword

Jason Olson — Mon, 15 Dec 2008 00:56:05 GMT

This question/conversation has come up quite often when chatting with friends and other developers. With the introduction of the "var" keyword in C# now, when should it be used (and, perhaps more importantly, when should it not be used). Here is a quick summary on my thoughts...

My personal feeling is that it's a problem if I have to rely on Intellisense in order to be able to tell what type a variable is when it is declared. It's important to keep the future audience in mind while you are writing code (this could be future developers needing to maintain your code, or even yourself years down the road). After all, writing code is the easy part. Reading it (and hence, reverse engineering it to a degree) is the hard part.

So, when you write code that requires another developer to use Intellisense (or go poking around other pieces of code that may be contextual irrelevant) to understand a piece of code, I would contend that you are not writing good code.

This brings us to the var keyword. Good usage? Using it to automatically infer variable types on declaration/instantiation lines of code:

var people = new List<People>();
var lookup = new Dictionary<string, SomeType>();

However, I really don't like when developers use the var keyword on a variable declaration based on the return of a method call. Without Intellisense, how am I supposed to be able to tell what type the variable is?

// This is *bad*, don't do this
var local = SomeMethod(...);

How about loop variables? My personal take (though I could go either way) is to not use the var keyword on loops:

// I prefer this
for (int i = 0; i < 10; i++)
{
...
}

// over this
for (var i = 0; i < 10; i++)
{
...
}

In general, I think it is important not to be a lazy coder and do something just because it makes it easier on you at the time. As a developer, you need to think about those that will come after you and maintain your code. Don't make it any harder on them than it needs to be. Their jobs are already hard enough.

What are your thoughts? Where do you use the var keyword? Where do you NOT use the var keyword?

Threading Basics: Race Conditions, Part 1

Jason Olson — Fri, 19 Sep 2008 08:13:42 GMT

I've talked in the past about the importance of parallel computing for all us developers. It's a trend in computer software and hardware architecture that is not a fad. Currently, in the US, it is nearly impossible to buy a new computer that has only a single core. We're even starting to see some of the first quad-core laptops hit the market.

It's becoming very important for developers to start dealing with parallel code. There's one problem: multithreaded development is hard. And in the class of Threading 101, Race Conditions is one of the first chapters you have to deal with.

So what is a Race Condition? According to Wikipedia, the source for all information on the Internet (emphasis mine):

"A race condition, or race hazard, is a flaw in a system or process whereby the output and/or result of the process is unexpectedly and critically dependent on the sequence or timing of other events. The term originates with the idea of two signals racing each other to influence the output first."

That's nice and all, but what does this mean to us developers? Let's look at a simple example. I have a Logger where I want to keep track of the number of messages that are logged.

   1: class Logger   2: {   3:     public static int TotalMessages = 0;   4:     5:     public void Log(string message)   6:     {   7:         // Do something with message   8:         TotalMessages++;   9:     }  10: }

Now let's call this method a bunch of times from four different threads and capture the total number of times Log message was called:

   1: int messagesPerTask = 200000;   2: int unitsOfWork = 4;   3:     4: var logger = new Logger();   5: Parallel.For(0, unitsOfWork, (taskNumber) =>   6: {   7:     for (int i = 0; i < messagesPerTask; i++)   8:     {   9:         logger.Log("Message " + i.ToString());  10:     }  11: });  12:    13: Console.WriteLine("{0} Expected", messagesPerTask * unitsOfWork);  14: Console.WriteLine("{0} Actual", Logger.TotalMessages);

What do you expect the output to be? The obvious answer is "well, we are adding 200000 messages on four different threads, so it's obviously 800000". Unfortunately, the obvious answer also happens to be the wrong answer. What's the right answer? It depends, and it can change every single time you run the application. For example, this were the results from the first time I ran the code:

800000 Expected
680354 Actual

Wait... how is this possible? Did we lose updates? Did I not call the method enough times? This surely must be a horrendous bug in the .NET Framework! Damn Bill and his blasted company. Trust me, it's not a bug. There's a good explanation of this behavior.

If you haven't written a lot of multithreaded code yet, the problem with the above code may not be obvious. Truth be told, there really isn't a problem with the code... IF you are only running the code on a single thread ever. But the likelihood of running on a single thread is becoming smaller and smaller. And as you can see, when we are running this in a multithreaded environment, there is most definitely a problem with the code.

A lot of .NET developers look at "TotalMessages++" and interpret it as one line of code, one execution, one instruction, etc. But there's the rub, it isn't. The code "TotalMessages++" is actually four instructions when compiled down to IL.

   1: L_0001: ldsfld int32 CSharpSandbox.Logger::TotalMessages   2: L_0006: ldc.i4.1    3: L_0007: add    4: L_0008: stsfld int32 CSharpSandbox.Logger::TotalMessages

These four lines essentially say the following:

Get the current value of TotalMessages
Get the value 1
Add the two numbers together
Save the result back into TotalMessages

Now let's imagine two threads executing the four steps above at the same time. Since threads won't be in perfect lock-step, they may be off by two steps (assuming the value of TotalMessages is currently 2):

[Thread 1] 1. Get the current value of TotalMessages (gets 2)
[Thread 1] 2. Get the value 1
[Thread 2] 1. Get the current value of TotalMessages (gets 2)
[Thread 2] 2. Get the value 1
[Thread 1] 3. Add the two numbers together (2 + 1)
[Thread 1] 4. Save the result back into TotalMessages (saves 3)
[Thread 2] 3. Add the two numbers together (2 + 1)
[Thread 2] 4. Save the result back into TotalMessages (saves 3)

So we've executed that code twice and at the end of the execution, TotalMessages has only increased by one. This is exactly what a race condition is. It's that simple. It's not as advanced as a concept as one might think.

This is why developers need to understand what race conditions are. A snippet of code that looks completely innocuous can cause some big problems when run in a multithreaded development. While future technologies will make writing parallel code easier, it won't prevent these types of problems from occurring. You still need to be aware of some of the common Threading 101 concerns/topics that exist today.

Building A Fluent Interface for MEF

Jason Olson — Sat, 05 Jul 2008 09:59:01 GMT

How would you like to use the following way to configure dependencies in MEF? A fluent interface with POCO support (no attributes necessary)? Yup.

            var resolver = new FluentResolver();
            resolver.Register<HelloWorld>().
                And<HelloGreeting>().As<IGreeting>().
                And<ConsoleOutputter>().As<IOutputter>();

            var domain = new CompositionContainer(resolver);

            // HelloWorld has dependencies on IGreeting and IOutputter
            var helloWorld = domain.Resolve<HelloWorld>();
            helloWorld.SaySomething();

Lately I've been digging more and more into the first CTP of the Managed Extensibility Framework (MEF) coming out of Krzysztof Cwalina's team here at Microsoft. By default, a developer needs to sprinkle Export and Import attributes in their classes at the point they are needing something to be injected, or on classes that need to be exported in order to be injected into other classes. However, if you don't like this behavior, MEF provides several extension points you can use to provide a different interface into MEF.

In my "ideal" Dependency Injection interface for MEF, there are several requirements that I would like:

No Export/Import attributes necessary; hence, support for POCOs (Plain Ol' CLR Objects)
Registration of types with container, not registration of object instances (where I would have to create the object myself before adding it's type to the container).
Simply ask container to resolve a type into an instance for me. Other than the container and resolver, none of my "domain objects" should be "new"-ed up by me.
No need to tell the CompositionContainer to Bind(). It should know about all the types necessary.
For "ease of use", I want to configure dependencies via a Fluent Interface.

I'm on a little bit of a Fluent Interface kick right now. I admit it. My name is Jason Olson and I'm a Fluent Interface junkie. If I could type emails via a Fluent Interface in code (rather than Outlook), I probably would. My addiction is just... that... bad.

Before we dig into how we will leverage MEF's extension points, let's just take a quick peek at the classes we are wanting to wire up via the interface shown above:

    class HelloWorld
    {
        public IGreeting Greeting { get; set; }
        public IOutputter Outputter { get; set; } 

        public void SaySomething()
        {
            // Our dependencies above determine where the output
            // is written to, and what the greeting will be.
            Outputter.WriteLine(Greeting.Greet());
        }
    }

    interface IGreeting
    {
        string Greet(); 
    }

    class HelloGreeting : IGreeting
    {
        public string Greet() 
        {
            return "Hello Fluent Interface!";
        }
    }

    interface IOutputter
    {
        void WriteLine(string message); 
    }

    class ConsoleOutputter : IOutputter
    {
        public void WriteLine(string message)
        {
            Console.WriteLine(message);
        }
    }

So how do we enable this new behavior? There are two primary MEF extension points we will use, a custom ComponentBinder and a custom ValueResolver. According to the CTP documentation (emphasis mine):

"The role of the ComponentBinder is to create a collection of primitives associated with its component. There is only one ComponentBinder per component. The CompositionContainer will use the collection of binders during the bind operation to determine how components need to be wired-up."

In this case, "collection of primitives" essentially means the export and imports of the component it is bound to. One of the interesting points to note is that the CompositionContainer uses these ComponentBinders to determine how various components need to be created. So for MEF to determine what the various imports and exports are for wiring up components, it can use our custom ComponentBinder to do so. So while the default ReflectionBinder will generate this information via attribute declarations on the components in question, we can change this behavior if we wish.

The other extension point we will use is a custom ValueResolver. Once again, according to the CTP documentation (emphasis mine):

"A ValueResolver allows the composition container to retrieve components from some sort of repository. The composition container’s bind operation has the single goal of satisfying all imports for all components that were explicitly added to it. During a bind operation, the composition container can query the ValueResolver for exports if it deems it necessary (e.g. no exports currently in the composition container satisfy a specific import, an import is requesting a collection of all available exports, etc.)."

To implement these two extension points, we will need two custom classes: FluentResolver and FluentBinder. Our FluentResolver is what we use to build up a map of our dependencies via the fluent interface shown above. When the FluentResolver is then passed into a CompositionContainer, we will go through our dependency map and crank out a bunch of FluentBinders that MEF can then use when needing to create various objects the user is asking for.

First, our FluentResolver. FluentResolver contains the methods that make up our fluent interface and that will hold the dependency map we are building up. And then we our FluentResolver is hooked up to a CompositionContainer, we will use this "dependency map" in order to build up all the FluentBinder instances that MEF will use to wire up all our dependencies.

    class FluentResolver : ValueResolver, IRegisterChainer
    {
        private Type lastRegisteredType;
        private IDictionary<Type, IList<Type>> exportTypes = new Dictionary<Type, IList<Type>>();
        private IList<Type> registeredTypes = new List<Type>();

        // The following three methods define our fluent interface
        // (Register<T>, And<T>, and As<T>).
        public IRegisterChainer Register<T>() where T : class, new()
        {
            if (!exportTypes.ContainsKey(typeof(T)))
            {
                exportTypes.Add(typeof(T), new List<Type>());
            }

            exportTypes[typeof(T)].Add(typeof(T));
            registeredTypes.Add(typeof(T));

            lastRegisteredType = typeof(T);
            return this;
        }

        public IRegisterChainer As<T>() where T: class
        {
            // Add exported type to last registered type (the call right
            // before .As<T>() in the fluent interface). This is used
            // to register a type as an interface, rather than the
            // concrete type.
            exportTypes[lastRegisteredType].Add(typeof(T));
            return this;
        }

        public IRegisterChainer And<T>() where T : class, new()
        {
            // Just a different way to register so that the fluent
            // interface is easily readable.
            return Register<T>();
        }

        // This is where the "magic" happens. When our container is set (like
        // when we are passed into the constructor of a container), we will
        // create all of our custom binders that MEF will then use to wire-up
        // dependencies.
        protected override void OnContainerSet()
        {
            base.OnContainerSet();

            foreach (var type in registeredTypes)
            {
                // An "Import" (read: injected dependency) is defined as any property whose
                // type is a type that is "exported" from any other registered type
                var imports = (from pi in type.GetProperties()
                               from export in exportTypes
                               where export.Value.Contains(pi.PropertyType)
                               select pi).Distinct();

                // Export all types our specific type has been asked to export and all the 
                // properties from above that are dependencies we need to inject.
                Container.AddBinder(new FluentBinder(type, exportTypes[type], imports.ToList()));
            }
            
            // Since all the dependencies are known from our fluent interface,
            // automatically bind the container so that the user doesn't have to
            // call Bind() themselves.
            Container.Bind();
        }

        public override CompositionResult<IImportInfo> TryResolveToValue(string name, IEnumerable<string> requiredMetadata)
        {
            // Same as TryResolveToValues below, except we just return a
            // single value, rather than a collection of values.
            var result = TryResolveToValues(name, requiredMetadata);

            return new CompositionResult<IImportInfo>(result.Succeeded, 
                result.Issues, 
                result.Value.First());
        }

        public override CompositionResult<ImportInfoCollection> TryResolveToValues(string name, IEnumerable<string> requiredMetadata)
        {
            // Based on all the custom binders we have created, have
            // the container get the various dependent components for us.
            return TryGetContainerLocalImportInfos(name, requiredMetadata);
        }
    }

IRegisterChainer is simply an interface our three fluent methods (Register<T>, And<T>, As<T>) return (and that FluentResolver implements) that allows us to keep on chaining our method calls one after the other, hence enabling our fluent interface.

    interface IRegisterChainer
    {
        // Allows registering another dependency into our resolver
        IRegisterChainer And<T>() where T : class, new();

        // Enables registering a depedency as a specific type (like
        // an interface) on top of the concrete type it directly implements
        IRegisterChainer As<T>() where T : class;
    }

And now on to our FluentBinder:

    class FluentBinder : ComponentBinder
    {
        // An instance of the type we are the binder for
        private object instance;

        // The types we export (could be our concrete type, interfaces, etc.)
        private IList<Type> exports;

        // Our properties that are dependencies needing resolving
        private IList<PropertyInfo> imports;
       

        public FluentBinder(Type type, IList<Type> exports, IList<PropertyInfo> imports) 
        {
            this.exports = exports;
            this.imports = imports;

            // In the future, we could use constructor injection here. For now,
            // just use the default constructor and property injection.
            instance = type.GetConstructor(new Type[] {}).Invoke(new object[] {});
        }


        public override IEnumerable<string> ExportNames
        {
            // Return the name of the Types we are Exporting
            get { return exports.Select(t => t.ToString()); }
        }

        public override CompositionResult Export() 
        {
            // Add our object instance into the container for every type
            // that we are exporting.
            foreach (var type in exports)
            {
                AddValueToContainer(type.ToString(), instance);
            }

            return new CompositionResult(true, new List<CompositionIssue>());
        }

        public override IEnumerable<string> ImportNames
        {
            // Return the name of the Types we need Imported
            get { return imports.Select(pi => pi.PropertyType.ToString()); }
        }

        public override CompositionResult Import(IEnumerable<string> changedValueNames) 
        {
            // Import every property we have that is a dependency
            foreach(var propertyInfo in imports)
            {
                // Inject an instance of the type of our property from the container
                var component = Container.TryGetBoundValue(propertyInfo.PropertyType.ToString(), 
                    propertyInfo.PropertyType);

                propertyInfo.SetValue(instance, component.Value, null);
            }

            return new CompositionResult(true, new List<CompositionIssue>());
        }
    }

This FluentBinder is essentially the heart of the our behavior. We use the the results from our FluentResolver that are passed in to our binder to let MEF know what types we need to import and what types we are exporting from the type FluentBinder is bound to.

The final thing we need to enable our desired API from above is an extension method to CompositionContainer called Resolve<T>() which we just give the type that we would like an instance of. I just happen to think this thin wrapper around TryGetBoundValue<T>() is easier to use and better to read.

    static class CompositionContainerExtensions
    {
        public static T Resolve<T>(this CompositionContainer domain)
        {
            return domain.TryGetBoundValue<T>().Value;
        }
    }

And now we can combine all the pieces together to build our sample application:

    class Program
    {
        static void Main(string[] args)
        {
            // Declare dependencies via a fluent interface.
            // No need for attributes, XML config, or 
            // registration of instances of objects.
            var resolver = new FluentResolver();
            resolver.Register<HelloWorld>().
                And<HelloGreeting>().As<IGreeting>().
                And<ConsoleOutputter>().As<IOutputter>();

            // Pass in our custom resolver and have it help
            // take care of the binding process.
            var domain = new CompositionContainer(resolver);

            // Ask the container for an instance of a type.
            var helloWorld = domain.Resolve<HelloWorld>();
            helloWorld.SaySomething();

            Console.ReadKey(true);
        }
    }

While the fluent interface might be seen as a potential "big departure" from the way MEF works out-of-the-box, you can see that it is very possible (and not too difficult) to change how dependencies are configured with MEF. You might want your configuration in an XML file, in a DSL defined in a map.txt file, in a database (no I don't know why you'd want that :P), etc. And no matter how you want it done, it is possible for you to do so with just a little coding.

Until next time, Happy Coding!

Obviously, this is just a sample prototype and doesn't have several features necessary in DI containers. So, more reason for me to write some more code :). Also, remember this is built on the first CTP of MEF, so the odds are that it will become out-of-date at a later time.