Piotr Włodek's Tech Blog

Fill up a WPF progress bar with a linear gradient

noreply@blogger.com (Piotr Włodek) — Mon, 27 Feb 2012 21:56:00 +0000

Not so long ago I was faced with a problem how to fill a rectangle with a gradient, which shows a progress, with the gradient stops depending on the current progress. I know I know, this probably tells you nothing. I believe a good visual example will save me a thousand words, so here it comes. This is what I wanted to say:

So lets discuss what we see here. We have three styled progress bars, each filled with the same background. The middle one serves as a reference point only. The middle and the last text boxes are filled with a regular linear gradient brush. And I mean regular, absolutely no magic there. When we change the progress using the slider, you can see that the rectangle which is used to show current progress shrinks or expands, but the last gradient behaves in a weird way. This is actually the default bahavior here. However, what I really expect is the behavior of the first progress bar – the fill gradient depends on the current progress. In other words, you can imagine 100% as the full gradient. Than, I want to crop it based on current progress.

So how to write a custom brush which would do that ? Yes, yes, you’re right. It’s not possible. You cannot write custom brushes in WPF. That’s sad but it’s true. No luck ? No! Attached behavior comes to the rescue! Whenever progress changes the attached behavior will recreate LinearGradientBrush and recalculate gradient stops based on the original gradient. It’s actuall simple, let’s have a quick overview of the code itself.

public class LinearGradientBrushBehavior : Behavior<RangeBase>
{
    protected override void OnAttached()
    {            
        AssociatedObject.Loaded += AssociatedObject_Loaded;
        AssociatedObject.ValueChanged += AssociatedObject_ValueChanged;

        var sourceBrush = AssociatedObject.Foreground as LinearGradientBrush;
        if (sourceBrush != null)
        {
            SourceBrush = sourceBrush;
        }
    }
        
    protected override void OnDetaching()
    {
        AssociatedObject.Loaded -= AssociatedObject_Loaded;
        AssociatedObject.ValueChanged -= AssociatedObject_ValueChanged;
    }

    private void AssociatedObject_Loaded(object sender, RoutedEventArgs e)
    {
        CalculateNewGradient(Progress);
    }

    private void AssociatedObject_ValueChanged(object sender, RoutedPropertyChangedEventArgs<double> e)
    {
        CalculateNewGradient(Progress);
    }

    private double Progress
    {
        get { return AssociatedObject.Value / (AssociatedObject.Maximum - AssociatedObject.Minimum); }
    }

    #region SourceBrush

    public LinearGradientBrush SourceBrush
    {
        get { return (LinearGradientBrush)GetValue(SourceBrushProperty); }
        set { SetValue(SourceBrushProperty, value); }
    }

    public static readonly DependencyProperty SourceBrushProperty =
        DependencyProperty.Register(
            "SourceBrush", typeof(LinearGradientBrush), typeof(LinearGradientBrushBehavior), new UIPropertyMetadata(null));

    #endregion
        
    private void CalculateNewGradient(double progress)
    {
        var brush = new LinearGradientBrush();
        brush.StartPoint = SourceBrush.StartPoint;
        brush.EndPoint = SourceBrush.EndPoint;

        foreach (var gradientStop in SourceBrush.GradientStops)
        {
            var offset = (1 - gradientStop.Offset) / progress;
            var newGradientStop = new GradientStop(gradientStop.Color, 1 - offset);
            brush.GradientStops.Add(newGradientStop);
        }

        ApplyNewGradient(brush);
    }

    private void ApplyNewGradient(LinearGradientBrush brush)
    {
        AssociatedObject.Foreground = brush;
    }
}

The most important part is the CalculateNewGradient method, which is called once when the control loads up and each time the progress changes. That method is responsible for calculating new offsets for all gradient stops. Recalculated gradient is than reapplied to the Foreground property. I don’t have to add that rectangle’s Fill is bound to it :) It’s also worth pointing out that this behavior works with RangeBase inherited controls, so you can utilize it to create nice looking Slider!

One thing to consider here is performance. I haven’t noticed any problems, even though each time progress changes, new instance of LinearGradientBrush is created. Which is good :) You can find the sources on my SkyDrive. Hope you like it!

WPF transitions using pixel shaders and Blend SDK

noreply@blogger.com (Piotr Włodek) — Wed, 02 Nov 2011 02:18:00 +0000

WPF transitions are a very nice way to turn standard, boring application interactions into great user experiences, and show the author pays attention to details. There are basically two ways of implementing transitions in WPF. You can do a manual transition using RenderTransform to modify the visuals’ position, scaling and rotation. Throwing in an opacity animation would improve the effect. This option is talked more in-depth here. However, there is a couple of problems with this approach. The biggest issue is that such transitions are CPU bound, since the transition is calculated on the main processor. The other problem is more prosaic – they are relatively hard to implement. The other way is to utilize pixel shaders to blend between two visuals’ images making the illusion of transition. Transitions done this way are GFX bound, offloading the CPU which can perform other useful tasks. Besides, they look just awesome, as you shall see in a moment :) There is a small problem associated with this approach, though. To write custom pixel shader, some GFX knowledge accompanied by HLSL might be required. Crafting nice effect probably would also require a bit of math :) Thankfully, there are some nice libraries packed with effects ready to use! So no worries, we will not be talking math here!
In this post I will discuss how to build a TransitionControl, which beautifully animates transitions from one visual state into the other. To demonstrate the effect, I updated my wizard demo (discussed here and here) so that transitions between consecutive steps are nicely animated. I will also show what it takes to add transition effect to regular TabControl. The following screens show the slide transition between two wizard steps.

And the following shows a transition within TabControl.

Pixel shader libraries
Pixel shaders were introduced in .NET Framework 3.5 SP1. By this time, Microsoft released really cool library called WPF Effects Library. The library is composed of two types of components: effects and transitions. Effects are successors to well known bitmap effects, and provide a way to alter how a visual is rendered on the screen (see this video). Transitions, on the other hand, provide a means to.. transition from one visual state to the other. Easy, huh ? We will leverage them to build robust TransitionControl.
These days the project seems not to be much updated, the latest version is 2.0 beta which targets .NET 3.5, but works with .NET 4.0 and Visual Studio 2010. The good news is that although this project is not longer maintained, most of the effects and transitions made its way to Blend 4.0 SDK! They are available in Microsoft.Expression.Effects.dll assembly.
Okay, so I introduced transitions, just show how to use them and probably we’re done here, right ? it turns out we’re not quite done here. Lets see what is the API for using a transition effect. The base TransitionEffect class, from which all transitions derive, is located in Microsoft.Expression.Interactions.dll assembly, and its public API is defined as follows:

public abstract class TransitionEffect : ShaderEffect
{
    protected TransitionEffect();
    public Brush Input { get; set; }
    public Brush OldImage { get; set; }
    public double Progress { get; set; }
}

The class inherits ShaderEffect, which makes it essentially a regular pixel shader effect. So it can be assigned to the Effect property of any UIElement. There are also two important properties: OldImage and Progress. The OldImage brush defines the look of the old visual, and the Progress, between 0.0 and 1.0, denotes where we are within the transition. So the flow when using any TransitionEffect is as follows:

Choose any transition effect and apply it to any UIElement which is the target visual we want to transition to
Get the VisualBrush which depicts the visual we transition from, and assign it to the OldImage property
Animate Progress property from 0.0 to 1.0 to perform the actual transition

As you can see, this is not very complicated, but far from being convenient. And this is where TransitionControl comes to play (I believe Telerik offers similar control).

Meet the TransitionControl
TransitionControl encapsulates the above three steps and provides a nice API to consume by the client. Let’s think for a moment, what is the most convenient API for the TransitionControl ? Yes, you’re right, it’s a ContentControl! ContentControl provides a Content property which is almost everything we care about. Whenever we change the Content property to something else, we expect to get a nice transition which smoothly goes from one visual state to the other. Having said that, let’s see the API of the TransitionControl.

public class TransitionControl : ContentControl
{    
    public TransitionSelector ContentTransitionSelector { get; set; }
    
    public TimeSpan Duration { get; set; }

    public IEasingFunction EasingFunction { get; set; }

    public bool EnableTransitions { get; set; }       
}

You can see that the TransitionControl is essentially a ContentControl. This is good, because, whenever you use ContentControl, you can swap it for TransitionControl and get the transitions for free! The second important thing is how actually TransitionControl knows about particular transition we want to use ? This is where TransitionSelector comes in. It is an abstract class which behaves similarly to DataTemplateSelector. It defines single method as show below.

public abstract class TransitionSelector
{
    public abstract TransitionEffect GetTransition(object oldContent, object newContent, DependencyObject container);
}

You implement this class and hand over a new instance to TransitionControl. You get both the old and new contents, so it is possible to write dynamic logic which selects transition based on a content. Nice, huh ? There are also two properties which drive the behavior of the transition. Duration determines the length of the transition, and EasingFunction allows to supply easing function :)

How does it work ?
The transition kicks of when the Content property changes. If the previous content was empty, of course no transition occurs. But if both old and new contents are presents, transition is triggered. The “magic” sits in the AnimateContent method, which is responsible for going through the three steps outlined previously.

private void AnimateContent(object oldContent, object newContent)
{
    var oldContentVisual = GetVisualChild();
    var tier = (RenderCapability.Tier >> 16);

    // if we dont have a selector, or the visual content is not a FE, do not animate
    if (EnableTransitions == false || ContentTransitionSelector == null || oldContentVisual == null || tier < 2)
    {
        SetNonVisualChild(newContent);
        return;
    }
    
    // create the transition
    TransitionEffect transitionEffect = ContentTransitionSelector.GetTransition(oldContent, newContent, this);
    if (transitionEffect == null)
    {
        throw new InvalidOperationException("Returned transition effect is null.");
    }

    // create the animation
    DoubleAnimation da = new DoubleAnimation(0.0, 1.0, new Duration(Duration), FillBehavior.HoldEnd);
    da.Completed += delegate
    {
        ApplyEffect(null);
    };
    if (EasingFunction != null)
    {
        da.EasingFunction = EasingFunction;
    }
    else
    {
        da.AccelerationRatio = 0.5;
        da.DecelerationRatio = 0.5;
    }
    transitionEffect.BeginAnimation(TransitionEffect.ProgressProperty, da);

    // create the visual brush which is the source of the "old content" image
    VisualBrush oldVisualBrush = new VisualBrush(oldContentVisual);
    transitionEffect.OldImage = oldVisualBrush;

    SetNonVisualChild(newContent);
    ApplyEffect(transitionEffect);
}

How to make transition aware TabControl
This task is super easy task! Just extract the default template for TabControl, and remove ContentPresenter with name PART_SelectedContentHost and provide the following XAML.

<Controls:TransitionControl 
  x:Name="PART_SelectedContentHost"
  Duration="00:00:01"
  Content="{TemplateBinding SelectedContent}"
  ContentTransitionSelector="{StaticResource TabControlTransitionSelectorKey}"
  Margin="{TemplateBinding Padding}" SnapsToDevicePixels="{TemplateBinding SnapsToDevicePixels}"/>

You will have to supply proper TransitionSelector. In the demo application, I used the following:

public class TabControlTransitionSelector : TransitionSelector
{
    private readonly Random _random = new Random();

    private readonly TransitionEffect[] _transitions = new TransitionEffect[]
    {
        new SmoothSwirlGridTransitionEffect(),
        new BlindsTransitionEffect(),
        new CircleRevealTransitionEffect(),
        new CloudRevealTransitionEffect(),
        new FadeTransitionEffect(),
        new PixelateTransitionEffect(),
        new RadialBlurTransitionEffect(),
        new RippleTransitionEffect(),
        new WaveTransitionEffect(),
        new WipeTransitionEffect(),
        new SlideInTransitionEffect { SlideDirection = SlideDirection.TopToBottom }
    };
    public override TransitionEffect GetTransition(object oldContent, object newContent, DependencyObject container)
    {
        var index = _random.NextDouble() * _transitions.Length;
        return _transitions[(int) index];
    }
}

Conclusion
In this post I presented how using pixel shader effects create really cool looking, GFX bound transitions. Since the control responsible for wiring up everything is a ContentControl, you can use it wherever you use regular ContentControl, and you will get the transitions for free.

Download
As always, you can download full sources from my Sky Drive.

Build your first WinRT component

noreply@blogger.com (Piotr Włodek) — Tue, 27 Sep 2011 19:35:00 +0000

I think that the dust has cleared after the Build Windows conference which took place two weeks ago. Since then blog posts started to show up talking about Metro style apps, WinRT, its impact on current skills, etc. Also, Microsoft released public preview of Windows 8, so it is about a good time to give it a try. So I installed Win8 on the latest Virtual Box, and it seems to work fine, apart from a few systems crashes per hour ;) So in this post, I want to show you what it takes to build simple yet functional WinRT component in native C++, and also will talk why you would do that. But before we jump right to the code, I would like to provide a brief overview of Windows 8 developer platform, and WinRT itself.

Windows Runtime

Microsoft says that WinRT is “a solid, efficient foundation for the new Windows 8 developer platform”. I love such marketing slang! So what WinRT really is? It is a framework (calling it a framework is a bit unfair, since WinRT is a part of the core of Windows OS, and is compiled each time Windows is built) for building Metro style apps.

This is important information. It means WinRT can only be used for developing metro style apps. Metro style apps, although perfectly legal on a desktop system, are especially meant for tablets. This is the environment where they truly shine! And tablets are the most important reason Microsoft has actually created it. Why ? How else would they provided fast and fluid user experience on an ARM based tabled cloacked at 1.6 GHz ? Would you run fully blown WPF apps there ? I doubt. Silverlight ? Better, but you can’t code it with C++. To compete with Apple iPad, they had to provide really fast solution. This is how MS come up with WinRT =)

Let’s have a quick look over the architecture. Oh, don’t be fooled by metro style apps being three times bigger than desktop apps. Microsoft tries very hard to emphasis Metro style Apps, though, as I said, they are mostly meant for tablets, so still most of the LOB applications will be delivered as a standard smart client desktop apps.

From the slide above we clearly see that WinRT is only about Metro style apps. There is also one more thing. For regular Desktop Apps, nothing really changes. So let’s put an end to statements saying that WPF and Silverlight are dead. They’re not! Silverlight 5 is coming out soon, with the RC version already available, and we have WPF 4.5 preview available as well, with cool new feature coming (be sure to check Jonathan Antoine’s blog).

So as I said, it turned out that Silverlight and WPF are still there, they’re all good, and they are XAML based. As you see, the brand new WinRT is also XAML based, so another way of looking at it is that it is yet another manifestation of XAML framework. We have WPF, we have Silverlight, and now we have WinRT.

WinRT has been entirely written in native C++. The did that because they wanted performance, and give the opportunity to C++ devs to build vNext apps for Windows. Besides, Microsoft is constantly saying that the performance is the top priority for them =) What is super important is that WinRT components can be consumed from a variety of languages, including C++, C#, VB, and JavaScript. To enable this scenario, MS baked in a support for metadata, which describes the WinRT objects. As a side note, the metadata uses standard CLR metadata format (ECMA 335), so it can be ILDASMed for instance ;) So each native WinRT component is packed up in a standard native dll, and is accompanied with *.winmd file, which carries all the metadata information for that dll. In the Win8 Developer Preview, all metadata files for standard WinRT dlls are located on C:\Windows\System32\WinMetadata.

As far as the Graphics & Media part is concerned, the framework is a bit similar to Silverligh. UIElement, FrameworkElement, it’s all there. What is different though is the default namespace. We were used to System.Windows.*, now everything is in Windows.*, with the UI part being located in Windows.UI.XAML.* namespace.

That is pretty much it when it comes to WinRT overview, at the end of this post are link to good articles discussing WinRT in more depth.

Why bother writing WinRT components

It comes without surprise that MS allows us to create custom WinRT objects. What’s great about it, is that we can leverage the same metadata system MS is using in the “standard” WinRT, which means we can code our WinRT object in any supported languages (currently C++, C#, VB) and consume it from other languages without any effort. This means we can write performance critical code in C++ and consume it in C#, without resorting to COM interop or P/Invoke. Awesome!

So answering the question, building WinRT components allows developers to share their codebase with other projects, written in any language, targeting any platform. Say you want to develop custom control. If you develop it in C# as a regular CLR dll, you will be able to consume it only in C#. But if you make it a WinRT object, you can leverage it from any Metro app. Okay, so why bother writing such component in C++ then? Because of performance! Do you know why Silverlight is faster than WPF ? Because it’s C++ under the hoods! Don’t believe ? Try reflecting Grid in SL ;)

Summing up this short paragraph, you definitely want to write WinRT component if you want to share you code with other WinRT objects, running on different platforms. And you want to do it in C++ because of the performance.

Writing custom panel in native C++

So finally, we reached to the most interesting part, which is the code. So here I will demonstrate how to develop custom, native WinRT object. To do so, I will use custom panel as an example. Let’s say we want to develop CircularPanel, which layouts all its children in a circle. Let’s begin, shall we ?

Go to Visual Studio 2011 For Windows 8 Developer Preview, and add new C# empty project. Here we will consume our C++ WinRT object. Now go again and add new project, this time use C++ and WinRT Component template. Delete the WinRTComponent1 source and header files, and add CircularPanel.cpp and CircularPanel.h files. You should have something similar in Solution Explorer.

Time to fill in some code! Open up CircularPanel.h file and paste in this code.

#pragma once

using namespace Windows::Foundation;

namespace WinRT
{
	namespace Controls
	{
		public ref class CircularPanel sealed : public Windows::UI::Xaml::Controls::Panel
		{
		private:
			float _maxChildHeight;
			float _maxChildWidth;

		public:
			CircularPanel ();
			~CircularPanel ();

		protected:
			virtual Size ArrangeOverride(Size finalSize) override;

			virtual Size MeasureOverride(Size availableSize) override; 
		};
	}
}

As you can see no rocket science there. We define our CircularPanel class as ref so that it will act as a reference type, and we derive it from Windows.UI.Xaml.Controls.Panel class. Please note we declare MeasureOverride and ArrangeOverride methods that we will override to provide panel’s functionality. Now let’s go to the pane source.

// CircularPanel.cpp

#include "pch.h"
#include "CircularPanel.h"
#include "math.h"

#define PI 3.1415926

using namespace WinRT::Controls;
using namespace Windows::UI::Xaml;
using namespace Windows::UI::Xaml::Controls;

float Max(float x, float y)
{
	if (x > y) return x;

	return y;
}

float Min(float x, float y)
{
	if (x > y) return y;

	return x;
}

CircularPanel::CircularPanel ()
{
}

CircularPanel::~CircularPanel ()
{
}

Size CircularPanel::ArrangeOverride(Size finalSize)
{
	Point centerPoint = Point();
	centerPoint.X = finalSize.Width / 2;
	centerPoint.Y = finalSize.Height / 2;

	float radius = Min(centerPoint.X, centerPoint.Y) - (_maxChildWidth + _maxChildHeight) / 4;
	float degreesPerChild = 360.0 / Children->Size;
	float currentDegree = 0;
	
	for (int i = 0; i < Children->Size; i++)
	{
		UIElement^ element = Children->GetAt(i);
		float x = centerPoint.X + radius * cos(currentDegree * PI / 180);
		float y = centerPoint.Y + radius * sin(currentDegree * PI / 180);
				
		Rect rect = Rect();
		rect.X = x - element->DesiredSize.Width / 2;
		rect.Y = y - element->DesiredSize.Height / 2;
		rect.Width = element->DesiredSize.Width;
		rect.Height = element->DesiredSize.Height;

		// Arrange child element
        element->Arrange(rect);

        currentDegree += degreesPerChild;
	}

	return finalSize;
}

Size CircularPanel::MeasureOverride(Size availableSize)
{
	for (int i = 0; i < Children->Size; i++)
	{
		UIElement^ element = Children->GetAt(i);
		element->Measure(availableSize);

		_maxChildWidth = Max(_maxChildWidth, element->DesiredSize.Width);
		_maxChildHeight = Max(_maxChildHeight, element->DesiredSize.Height);
	}

	return availableSize;
}

There is a little bit of math involved, but rather easy stuff. I don't want to discuss the code itself, just note the syntax. For example, we reference reference types with ^ (like UIElement^). Children collection doesn’t have Count property but Size field instead. Yeah, we’re in C++ world!

Now its time to tell our C# app about our native WinRT project. And this is were troubles start ;) Normally, we would go to Add Reference dialog and add it from Solution projects (no need to manually pick up the assembly), but this feature seems not working right now, although some say it is possible to add C++ WinRT project from Add Reference dialog, just clean the native project before. Didn’t work for me, but who knows, maybe will work for you! So instead go to Add Reference dialog and hit the Browse button. Navigate to the root folder of your solution, go to Debug and select the YourNativeProjectName.winmd file. This is quite interesting step – we reference a native dll using its Windows metadata file. So when you go ahead and compile the solution, you will see… a build error! At least on x64 bit machine.

I’m not sure if you get exactly the same error, although you should. So the problem is that our native component is targeting Win32 platform, which is x86, but we reference it from Any CPU C# project. This won’t work. Go to Configuration Manager and change C# project to target x86.

So now if you go ahead and compile, you will get another error.

This one is also easy to fix. So our component uses Platform.IDisposable, which needs to be referenced. So go back to Add Reference dialog and add Microsoft.VCLib dependency. Now the compilation should succeed.

So since the compilation succeeded, let’s actually make use of our WinRT object. But there is yet another gotcha! For unknown reason, I couldn’t get this panel to work in XAML. I got compile error saying this component is unknown. Referencing it from code worked, however.

partial class MainPage
{
    public MainPage()
    {
        InitializeComponent();

        Loaded += new RoutedEventHandler(MainPage_Loaded);
    }

    private void MainPage_Loaded(object sender, RoutedEventArgs e)
    {
        CircularPanel panel = new CircularPanel();

        panel.Children.Add(new Button() { Content = "1", Width = 100, Height = 100 });
        panel.Children.Add(new Button() { Content = "2", Width = 100, Height = 100 });
        panel.Children.Add(new Button() { Content = "3", Width = 100, Height = 100 });
        panel.Children.Add(new Button() { Content = "4", Width = 100, Height = 100 });
        panel.Children.Add(new Button() { Content = "5", Width = 100, Height = 100 });
        panel.Children.Add(new Button() { Content = "6", Width = 100, Height = 100 });
        panel.Children.Add(new Button() { Content = "7", Width = 100, Height = 100 });
        panel.Children.Add(new Button() { Content = "8", Width = 100, Height = 100 });
        panel.Children.Add(new Button() { Content = "9", Width = 100, Height = 100 });

        LayoutRoot.Children.Add(panel);
    }
}

When you run the app, you should see a couple of buttons arranged in a circle :)

Conclusion

Microsoft did pretty good job with latest Win8. The new metro style apps, though meant for tablets, are truly great. When it comes to development, the Developer Preview is still pretty rough on the edges, but its about a good time to start playing with it, and upgrading skills. When it comes to WinRT development, it feels like WPF/SL.The base concepts like dependency properties, routed events, XAML, it’s all the same! This is a big strength of this platform. Well done MS!

Posts worth reading

A bad picture is worth a thousand long discussions

My thoughts about Build, Windows 8, WinRT, XAML and Silverlight

Welcome to Zombieland, the Metro Style Land of WinRT and the Undead

Win8, Metro Apps and Silverlight

Isolating MEF components

noreply@blogger.com (Piotr Włodek) — Tue, 26 Jul 2011 21:56:00 +0000

What Managed Extensibility Framework does well is component discovery and composition (when saying component I usually refer to MEF part). This is not a big surprise as it was designed to do so. However, one particular area where MEF has nothing to say about is component isolation. What is it ? Component isolation allows for plugins to work together without impacting each other. If one component fails, the rest of the system remains stable as nothing has ever happened. Yes, I know – when designing custom software solutions, we rarely care about plugins (too bad), but about component isolation, we don’t care at all. Why ? Most notably because dealing with component isolation is not an easy task. Since the best way to isolate components is to host them in a separate process, there has to be a fast IPC mechanism, and there is no single address space. Because we have calls across process boundaries, we have to serialize arguments on one side, deserialize them on the other, etc. Quite a bit of work there.

Some of you are probably familiar with System.AddIn namespace, better known as Managed Addin Framework. It has shipped long time ago, in .NET 3.0 if I remember well. This framework provides robust plugin infrastructure, and yes, it supports component isolation on App Domain and Process levels (okay there is also no isolation if you want to leverage plugins only). There is one problem with MAF, though. It has steep learning curve making it hard to jump into it. I never heard someone is using it in a production environment. Alternative ? Haven’t heard about yet. If you had, drop me a line please :)

Recently I have been thinking about creating custom component isolation mechanism and integrating it with Managed Extensibility Framework. Although not that straightforward, I managed to create special, dedicated catalog which can instantiate MEF parts in a separate AppDomain or even a separate process!

Meet the IsolatingCatalog

The IsolatingCatalog is responsible for doing all the magic. It is a decorating catalog, meaning it accepts another catalog, scans all its parts looking for those which need to be isolated, and then instantiates the parts accordingly. The API for the catalog is extremely simple. All you have to do is to tell MEF that a part has to be isolated. To do so, you can use custom export attribute or custom metadata attribute assuming you’re doing the export your way. Here is an example:

[IsolatedExport(typeof(IFakePart), Isolation = IsolationLevel.Process)]
public class FakePart1 : IFakePart
{
}

IsolatedExportAttribute is a custom export attribute which adds some metadata to the exported part, which is interpreted by the IsolatingCatalog so that it knows what to do with the export. The core property is the Isolation property of type IsolationLevel. Not surprisingly, it defines the isolation level for the part :) And the isolation level can be None (mostly used for testing only), AppDomain, and Process. I guess they are self explanatory. As I said, you can also use IsolatedAttribute, which is a custom metadata attribute.

[Export(typeof(IFakePart)), Isolated(Isolation = IsolationLevel.None)]
public class DisposableFakePart1 : IFakePart, IDisposable
{
}

What else can you define for an isolated export ? All properties are specified in the IIsolationMetadata interface which is defined as follows:

public interface IIsolationMetadata
{
   /// <summary>
   /// Gets the isolation for a part.
   /// </summary>
   IsolationLevel Isolation { get; }

   /// <summary>
   /// Indicates if a new host should be created for a new instance of the part.
   /// </summary>
   bool HostPerInstance { get; }

   /// <summary>
   /// Gets the name of the isolation group. Used to make sure parts which
   /// defined the same name will be hosted in the same activation host.
   /// </summary>
   string IsolationGroup { get; }
}

With HostPerInstance property you can instruct the runtime to create separate host each time a part is created. I will cover hosts in much more details later on, right now a host is an activation host which, heh, hosts the instance of the created part. And IsolationGroup property is nothing more than a name for the activation host. If two or more parts specify the same name, they will be hosted in the same activation host, be in a separate AppDomain or a process. Note this interface is implemented by both the custom export and custom metadata attribute ensuring you can achieve the same results using either of the approaches.

Last thing to cover, although pretty straightforward, is how to use the catalog itself. As I said, it is a decorating catlog, and there is no philosophy is setting it up:

var typeCatalog = new TypeCatalog(typeof(TempPart), typeof(FakePart1));
var isolatingCatalog = new IsolatingCatalog(typeCatalog);
var container = new CompositionContainer(isolatingCatalog);

var part = container.GetExportedValue<TempPart>();

Let’s stop here for one second, and let’s assume FakePart1 is instantiated in isolation, with TempPart consuming it:

[Export]
public class TempPart
{
   [Import]
   public IFakePart Part { get; set; }
}

What gets injected into Part property ? If we run this code in debug mode, we would see this:

This is very important. What gets injected is a proxy supporting the IFakePart contract rather than a concrete FakePart1 implementation. Why ? Of course because the original FakePart1 is instantiated in isolation, typically in a separate process or AppDomain, so what the client gets is a proxy which serializes all calls to the concrete implementation. Seems obvious, but I wanted to stress it :)

Demo

Now that you have seen how to make isolated parts, it’s time for a little demo. I put a simple app (I took a simple MDI sample from Caliburn project) which displays “movies” from various providers. It shouldn’t be a surprise that each movie provider is a MEF part, and some of them are working properly, and some of them are not.

Lets have a quick look at how each provider is exported:

[IsolatedExport(typeof(IMovieProvider), HostPerInstance = true, Isolation = IsolationLevel.Process, IsolationGroup = "SomeName")]
public class Provider1 : IMovieProvider
{
}

You can see that each provider is instantiated in a separate, named activation host. However, because all providers specify the same IsolationGroup, there will be a separate process per each three instances of the providers. Also, the app supports tabbed interface, with each tab getting its own set of providers. This means each tab will have its own process hosting the providers, which can easily be verified in the Task Manager (three tabs above means three processes below):

This mimics the Google Chrome browser approach, where each tab is hosted in a separate process. Okay, lets break something. Provider 3, when executed 2 times, will throw an exception on a separate thread. This is of course by design :) What will happen ? Normally, the application would crush and the process would terminate. However, because the logic which will fail is hosted in a separate process, that process would crush leaving the main app intact. As if this was not enough, the API allows to intercept failures, giving the ability to display error to the user:

As you see, even though there was a critical error in one of the providers, the application remains stable. If we go to the Task Manager we will see two processes hosting the providers, as the third one just failed. Btw, make sure you manually copy PluginContainer.exe (this guy can host MEF parts in it) to the bin folder. In feature releases, I will link this assembly directly to IsolatingCatalog.

Lack of features

Although working, this solution is not perfect. One of the drawbacks is that if a developer wants to isolate a part, it has to be exported accordingly. I think it would be nice to have the ability to setup isolation on the import level, so that even though the part developer didn’t plan for isolation, the import side would switch the isolation on. I imagine there would be IsolatedImportAttribute which could do the trick. The other thing is I’m using WCF for IPC. At first it seems okay, but creating WCF host is a costly operation, thus you will notice a slight delay when opening new tabs in the above demo. Perhaps it would be good to craft custom IPC based on named pipes ? Last thing is lack of dependency injection, since we might operate in a different address space. The good news is that it should be possible to address this; WCF supports duplex channel communication on named pipes binding, so I could use proxy to communicate back with the host application. This is pending on my TODO list :)

Download

Although namespace suggests IsolatingCatalog is part of MefContrib, it is not. It’s not because this is a POC rather than something production ready. I wrote it mainly to prove it is possible to isolate MEF parts. Having said that, I think the approach chosen is good (inproc WCF with named pipes binding is used for the IPC purposes), and I would love to see this being part of MefContrib someday. The only thing is time needed to add more test cases, doing a cleanup, etc. If you feel you could help me with that, drop me a line and we can work together!

To download the IsolatingCatalog, just go to my MefContrib fork and download isolation branch. The demo presented above can be downloaded from my skydrive below.

Conclusion

This post covered a working solution which enables to activate MEF parts in a separate AppDomain or even a separate process. Next post will cover how the isolation is being handled by IsolatingCatalog. Although not yet completed, my approach seems working fine, and after extensive testing I think it will make its way to the MefContrib. In the meantime, if you feel you could contribute to that catalog, either from MEF or isolation perspectives, fell free to contact me so that we might exchange ideas, etc. Hope you liked it!

Introducing convention based programming for Managed Extensibility Framework

noreply@blogger.com (Piotr Włodek) — Sat, 09 Apr 2011 12:23:00 +0000

More than a year ago my friend @TheCodeJunkie wrote a very nice addition to Managed Extensibility Framework – the ConventionCatalog. Since then it’s a part of MefContrib project. However, I haven’t seen many people using it. My guess is that there is no much information about it, besides this post. So in this post I will discuss what a convention model is, and how to use it!

What is ConventionCatalog ?

Convention model (aka. ConventionCatalog) allows you to specify conventions to produce parts, exports and imports. Okay, this is all fine, but give me an example! Here is a convention you can define: For every type in assembly MyCompany.MyFantasticProgram, if a type implements IWidget, please export it with contract type IWidget and import property named ViewModel. Nice, huh? Say you have Widget1 and Widget2 classes implementing IWidget interface. They will be automatically exported, and moreover, they don’t have to be attributed using standard MEF attributes!!! This is because the ConventionCatalog defines an extensible mechanism for writing such conventions! And you can write your own easily! One thing to note about the above convention – it will be applied to many types, particularly all implementing the IWidget interface. This is important as you don’t have to explicitly export all the classes individually. At the same time, it is perfectly legal to apply a convention to a single type. Example? If you ever encounter Widget123 type, please export it using IWidget contract type and add Location metadata with a value of Location.Left (enumeration). Here, only a single class (part) will be affected – the Widget123 class. Now you have a pretty good understanding what conventions are in the beautiful world of MEF, but how can I specify them in a program ? So as I stated previously, the catalog is extensible, so.. any possible way of specifying the conventions is… possible! Originally, @TheCodeJunkie developed a pretty nice fluent interface for defining them (as part of MefContrib 1.1 I’ve added some extension methods to ease the use of fi). Here is a code which defines the initial convention (it does not specify where to look for the types to apply it – be patient)

Part()
    .ForTypesAssignableFrom<IWidget>()
    .ExportAs<IWidget>()
    .ImportProperty("ViewModel");

Recently, I have developed a registration mechanism which enables to specify parts via the configuration file – App.config. Next section outlines both methods using a simple use case.

How can I use it ?

Let’s begin with a simple scenario. Let’s build a console application which can display a list of movies from various data sources. Here are the main classes and interfaces involved in the design: The core interface is IMovieProvider which provides an abstraction over any movie repository and has only one method returning a list of movies from a single movie source. It also has two dummy implementations – nothing interesting. This interface is consumed by the MovieLister class which implements IMovieLister and acts as a facade on top of the providers. It simply returns all movies from all providers available, with optional filtering by movie title. MovieLister also performs some simple logging, and the logger is injected using the constructor injection. The complete code for that class is right here:

public class MovieLister : IMovieLister
{
    private readonly ILogger _logger;

    public MovieLister(ILogger logger)
    {
        _logger = logger;
    }

    public IMovieProvider[] Providers { get; set; }

    public IEnumerable<Movie> GetMovies()
    {
        var movies = Providers
            .SelectMany(movieProvider => movieProvider.GetMovies())
            .ToList();
            
        _logger.Log(string.Format("Loaded {0} movies.", movies.Count));

        return movies;
    }

    public IEnumerable<Movie> GetMoviesByName(string name)
    {
        var movies = GetMovies()
            .Where(m => m.Name.Contains(name))
            .ToList();

        _logger.Log(string.Format("Found {0} movies matching '{1}'.", movies.Count, name));

        return movies;
    }
}

Note that there is no sign of standard MEF Export/Import attributes, and the constructor is not attributed with ImportingConstructor! Finally, there is a Program class which wraps the app. Here’s the code:

public class Program
{
    [Import]
    public IMovieLister MovieLister { get; set; }

    public static void Main(string[] args)
    {
        var p = new Program();
        p.Init();
        p.Run();
    }

    private void Init()
    {
        var conventionCatalog = new ConventionCatalog(new MoviePartRegistry());
        var container = new CompositionContainer(conventionCatalog);

        // Composing this part will inject MovieLister property
        container.ComposeParts(this);
    }

    private void Run()
    {
        var movies = MovieLister.GetMoviesByName("Movie");
        foreach (var movie in movies)
        {
            Console.WriteLine(movie.Name);
        }
    }
}

No doubt the most interesting part in the above code is the Init() method. I create there the ConventionCatalog (note this is the only catalog used in this example) and pass an instance of some registry. And here we came to the very important thing: all conventions are defined (or I should rather say can be understood) thanks to the IPartRegistry interface. So to introduce a custom way of defining conventions, you have to implement that interface (if you want to understand some internals of how ConventionCatalog works, read this post). By default, MefContrib 1.1 ships with two implementations:

PartRegistry – this class provides fluent interface to register part/export/import conventions,

ConfigurationPartRegistry – this class provide the XML way of specifying conventions.

Okay, so let’s see what it takes to register our parts using fluent interface.

public class MoviePartRegistry : PartRegistry
{
    public MoviePartRegistry()
    {
        // Apply the conventions to all types int the specified assembly
        Scan(c => c.Assembly(typeof(Program).Assembly));
            
        Part<MovieLister>()
            .MakeShared() // make this part shared
            .ExportAs<IMovieLister>() // and export it with contract type IMovieLister
            .ImportConstructor() // use constructor injection
            .Imports(x =>
            {
                x.Import<MovieLister>() // import on part MovieLister
                    .Member(m => m.Providers) // member named 'Providers'
                    .ContractType<IMovieProvider>(); // with contract type IMovieProvider
            });

        Part()
            .ForTypesAssignableFrom<IMovieProvider>()
            .ExportAs<IMovieProvider>();

        Part<LoggerImpl>()
            .MakeShared()
            .ExportAs<ILogger>();
    }
}

I derive from PartRegistry (although this is not a requirement, I prefer to do this that way) and do two things there. First, I specify to which types I want to apply my conventions. This is done through a nice lambda expression. What it does under the hoods ? It creates appropriate type scanners. A type scanner (anything implementing ITypeScanner interface) is responsible for returning all the types for which the user wants to assign conventions, if there are any applicable). Out of the box, there are:

TypeScanner, which can return user specified types,

AssemblyTypeScanner – returns all the types from given assembly,

DirectoryTypeScanner – returns all the types from all assemblies from a given disk folder,

AggregateTypeScanner – aggregates types from various type scanners.

Does it resemble you something ? Yes! Catalogs from MEF of course! This is because MEF catalogs are responsible for pulling parts/exports/imports from types. Similarly, we obtain types for which we want to apply the conventions. Okay, that’s all in terms of how to specify types for conventions. Lets move on to how to actually specify a convention. There’s a single method called Part() which returns PartConventionBuilder which has a nice fluent API to define part conventions. Part() method comes in two flavours – generic and nongeneric. The difference is that the generic Part<PartType>() method creates a convention in a strongly typed manner and applies that convention only to the part type specified as a generic type argument. However, if you want to leverage strong typing and specify conventions for other types as well, you can force it using ForTypesAssignableFrom() method. Actually, to specify types for which you want to apply the convention, you can use any of the For*() methods. It would be pointless to further explain the API, please play with it and let us know how does it feel – we can always improve! You probably have noticed how nicely IMoveProvider instances are exported. But what if we wanted to be able to specify which providers we want to use ? Of course there are many ways of achieving this, including leveraging metadata facilities of MEF. One method could also be to specify movie providers in the App.config file rather than exporting all IMovieProvider implementations using a convention. Let’s explore that possibility.

To configure parts using XML, we need to add another part registry to convention catalog. Change the Init() method to this:

private void Init()
{
    var conventionCatalog = new ConventionCatalog(
        new ConfigurationPartRegistry("mef.configuration"),
        new MoviePartRegistry());
    var container = new CompositionContainer(conventionCatalog);

    // Composing this part will inject MovieLister property
    container.ComposeParts(this);
}

ConfigurationPartRegistry class accepts a string representing the name of the config section used to configure parts. Next, remove the fluent registration for IMovieProviders. Finally, add the App.config with the following content:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section
      name="mef.configuration"
      type="MefContrib.Hosting.Conventions.Configuration.Section.ConventionConfigurationSection, MefContrib" />
  </configSections>

  <mef.configuration>
    <parts>

      <part type="ConventionCatalogDemo.MovieProvider1, ConventionCatalogDemo" creationPolicy="Shared">
        <exports>
          <export contractType="ConventionCatalogDemo.IMovieProvider, ConventionCatalogDemo" />
        </exports>
      </part>

      <part type="ConventionCatalogDemo.MovieProvider2, ConventionCatalogDemo" creationPolicy="Shared">
        <exports>
          <export contractType="ConventionCatalogDemo.IMovieProvider, ConventionCatalogDemo" />
        </exports>
      </part>
      
    </parts>
  </mef.configuration>

</configuration>

Well, what do we have in here ? :) We have a MEF configuration specifying a set of parts. Each part must have a full .NET type associated with it (type name + assembly). The part (not surprisingly) can have a set of exports it offers and of course a set of imports it consumes. Each export can specify:

contractType – type of the contract,

contractName – name under which the export will be available,

member – name of the member of the part to export (leave empty to export the whole part itself),

metadata – a collection of metadata-items specifying metadata that will be attached to the export.

Each import can specify:

contractType – type of the contract,

contractName – name used to resolve the import,

member – name of the member of the part to import,

creationPolicy – required creation policy,

allowDefault – whether the import allow default values,

isRecomposable – whether the import is recomposable,

required-metadata – a collection of metadata-items specifying required metadata.

To specify a set of imports for a part use imports xml element and fill it with import xml elements. I guess everything is self explanatory. If you have any doubts, pleas see MefContrib.Tests project to see some more examples.

Where can I find it ?

ConventionCatalog discussed in this post is available in MefContrib project. New ConfigurationPartRegistry ships as part of the MefCotrinb 1.1. Please download sources and binaries from mefcontrib.com. Sample code used in this post can be downloaded here. There is also another sample application (WPF based), which shows how ConventionCatalog can be used. You can download it from our official MefContrib-Samples Github repository. Here’s the screenshot for that app: Enjoy and let me know if you like it!

Integrating Castle Windsor with MEF

noreply@blogger.com (Piotr Włodek) — Tue, 29 Mar 2011 12:47:00 +0000

Some time ago I developed a small chunk of code which enabled Unity and Managed Extensibility Framework to consume each others components (see my posts here and here). After a while I hooked up with @TheCodeJunkie who was, and still is, responsible for managing MefContrib project, which aims at delivering high quality MEF extensions developed by the community. Soon, my integration layer became a part of that library! Yeah, I was excited =) After a while, I posted a refined version. Basically, I extracted some generic code from the existing Unity integration stuff which could be reused with other DI containers. So in this post I want to discuss a simple adapter for Castle Windsor which is built using that infrastructure and enables MEF to consume components registered in Windsor container.

Implementation

All the required stuff lives in MefContrib.Containers namespace (MefContrib.dll assembly) which has been renamed from MefContrib.Integration as the new name is more meaningful. There is one interface and one ExportProvider which are interesting in this scenario. IContainerAdapter is an interface which encapsulates basic behaviour of a typical IoC container. The ContainerExportProvider class then uses that interface to extract relevant components from the IoC and provides them to MEF. So the only part missing from the equation is the actual IContainerAdapter implementation for Windsor Container. Unsurprisingly, it is very simple. Here it comes:

public class WindsorContainerAdapter : ContainerAdapterBase
{
    private readonly WindsorContainer _container;

    public WindsorContainerAdapter(WindsorContainer container)
    {
        if (container == null)
        {
            throw new ArgumentNullException("container");
        }

        _container = container;
        _container.Kernel.ComponentRegistered += ComponentRegisteredHandler;
    }

    private void ComponentRegisteredHandler(string key, IHandler handler)
    {
        RegisterCastleComponent(handler);
    }

    public override object Resolve(Type type, string name)
    {
        return name == null
                    ? _container.Resolve(type)
                    : _container.Resolve(name, type);
    }

    public override void Initialize()
    {
        var handlers = _container.Kernel.GetAssignableHandlers(typeof (object));
        foreach (var handler in handlers)
        {
            RegisterCastleComponent(handler);
        }
    }

    private void RegisterCastleComponent(IHandler handler)
    {
        var name = handler.ComponentModel.Name;
        var type = handler.Service;

        // By default, Windsor assigns implementation's full name for the key,
        // but for a default key we want to pass null instead
        if (handler.ComponentModel.Implementation.FullName == name)
        {
            name = null;
        }

        OnRegisteringComponent(type, name);
    }
}

All we have to do is to inform ContainerAdapterBase that a component has been registered within the container so that the ContainerExportProvider knows which types are available. In the Initialize method we have a chance to register components which were registered in the IoC container before the adapter had a chance to intercept this information itself. The Resolve method will be called by MEF in order to get a component from IoC.

Usage

The usage is pretty straightforward. Let’s assume we have IFoo service which maps to Foo implementation. Here’s the code which registers these types within Castle Windsor and then IFoo is consumed by MEF.

var windsorContainer = new WindsorContainer();
var provider = new ContainerExportProvider(new WindsorContainerAdapter(windsorContainer));
var compositionContainer = new CompositionContainer(provider);

// Setup Castle Windsor
windsorContainer.Register(Component.For<IFoo>().ImplementedBy<Foo>());

var fooExport = compositionContainer.GetExport<IFoo>();

Of course, named registration is supported. Also MEF can resolve all IFoo implementations if it happens that IFoo is mapped to more than one implementation (thanks to named registration). See all the tests available in the provided solution.

Where can I find this ?

This code with some NUnit tests is available as a sample for the MefContrib project. You can find its sources at https://github.com/MefContrib/MefContrib-Samples.

Enjoy!

Geeks On Tour – Me speaking about MEF/MefContrib / Extensibility

noreply@blogger.com (Piotr Włodek) — Tue, 22 Mar 2011 17:06:00 +0000

I’m happy to announce that between April 18th and 20th 2011 I will be speaking on Geeks on Tour roadshow! Three days, three cities – Katowice, Wrocław, Poznań, two presentations each day. Wondering what MEF is ? How does it relate to IoC and Managed Addin Framework ? When to choose which ? What’s MefContrib and how it can help you ? How to write your custom MEF extensions ? Join me on the talks to find out this and many more! You can find more details about the event, including detailed agenda, on geeksontour.pl official page!

I will be covering all the aspects regarding MEF, its strong and week sides, how does MEF relate to other technologies. I will be showing some of the cool features MEF team is preparing as part of MEF 2 release. I will show some cool features which are part of MefContrib project. Finally, I will deep dive into MEF internals, I will show how to write custom exporters and catalogs. The presentations will be held in Polish. Entrance is free :) See you there!

Presentation and full source code is available below.

Introduction to InterceptingCatalog – Part II – Open Generics Support

noreply@blogger.com (Piotr Włodek) — Sun, 19 Dec 2010 18:31:00 +0000

In the previous post I have described how to setup interception using the InterceptingCatalog and InterceptionConfiguration class. Just to remind you, the interception allows you to take control over the exported instances thanks to the IExportedValueInterceptor interface. Although this is the primary functionality, there is other bunch of stuff possible to do with the catalog. In this post I am going to show how to enable open-generics support for MEF using both the InterceptingCatalog and the decorating GenericCatalog. I will then introduce the IExportHandler interface which gives the ability to do some nice filtering based on a given criteria as well as to add new exports on the fly. The open generics support implementation is based on the on the fly export creation (thanks to the IExportHandler interface) as well as thing called part rewriting. Keep reading to find out more!

The problem

One of the biggest problem people complain about is the lack of open-generics support in MEF. You can read about this issue here, here and here (I advise you see these entries!). The canonical example folks use concerns IRepository<T>. Imagine the following code:

public interface IRepository<T>
{
  T Get(int id);

  void Save(T instance);
}

[Export(typeof(IRepository<>))]
public class Repository<T> : IRepository<T>
{
  public T Get(int id)
  {
      return (...);
  }

  public void Save(T instance)
  {
      Console.WriteLine("Saving {0} instance.", instance.GetType().Name);
  }
}

/// <summary>
/// Fake customer.
/// </summary>
public class Customer { }

[Export]
public class CustomerViewModel
{
  [Import]
  public IRepository<Customer> Repository { get; set; }
}

So what happens here ? We simply export a generic implementation of the generic interface IRepository<T> with an open-generic contract type, and we import a closed-generic part based on the open generic contract. Unfortunately, this isn’t supported out of the box in MEF. However, thanks to MefContrib, it is!

How can I get it ?

Open generics support shipped initially in the MefContrib 1.0 release. However, it had limited capabilities as the open generics worked only when generic types were exported using the InheritedExport attribute. To get the updated version, which enables to do things like the above, you have to download MefContrib repo and compile the sources yourself. Updated samples, including those presented here, are available in the MefContrib-Samples repo. Go and get them =)

Container setup

There are two ways of enabling open generics support. You can either use more verbose syntax using the InterceptingCatalog, or you can leverage the GenericCatalog. The GenericCatalog is noting more than a convenient decorating catalog which internally uses the InterceptingCatalog.

The first thing to do is to provide mapping between open generic interface and its implementation. This step is mandatory since the underlying infrastructure requires to produce export based on the concrete implementation. This export is produced on the fly, which means it is not contained in any composable catalog, but is created when it is needed. To map the contract type to its implementation you can either implement IGenericContractRegistry interface or inherit the GenericContractRegistryBase class. The implementation which supports the above example is presented below.

[Export(typeof(IGenericContractRegistry))]
public class MyGenericContractRegistry : GenericContractRegistryBase
{
  protected override void Initialize()
  {
      Register(typeof(IRepository<>), typeof(Repository<>));
  }
}

Important: the mapping is required only when you export the generic class with explicitly given contract type (like in the example). If you export generic class with its default contract type, no mapping is required!

Next is what you have probably expected – the catalog setup.

// Create source catalog
var typeCatalog = new TypeCatalog(typeof(CustomerViewModel), typeof(MyGenericContractRegistry));

// Create the interception configuration and add support for open generics
var cfg = new InterceptionConfiguration()
  .AddHandler(new GenericExportHandler());

// Create the InterceptingCatalog and pass the configuration
var interceptingCatalog = new InterceptingCatalog(typeCatalog, cfg);

// Create the container
var container = new CompositionContainer(interceptingCatalog);

// Get the repository
var repository = container.GetExportedValue<CustomerViewModel>().Repository;

After creating the interception configuration, we add the GenericExportHandler instance which is responsible for creating closed generic parts. This class implements the IExportHandler interface, which I will introduce in a moment. Meanwhile, let’s see the less verbose and cleaner setup routine.

// Create source catalog
var typeCatalog = new TypeCatalog(typeof(CustomerViewModel));

// Create catalog which supports open-generics, pass in the registry
var genericCatalog = new GenericCatalog(new MyGenericContractRegistry());

// Aggregate both catalogs
var aggregateCatalog = new AggregateCatalog(typeCatalog, genericCatalog);

// Create the container
var container = new CompositionContainer(aggregateCatalog);

// Get the repository
var repository = container.GetExportedValue<CustomerViewModel>().Repository;

Instead of creating the InterceptingCatalog, the GenericCatalog is created. This concludes how to setup MEF to support open generics. Next sections explain how stuff works, without digging into implementation details though. If you are curious, keep reading!

How does it work ?

You are maybe asking yourself – given the export definition below – how does MEF know that when importing say IRepository<Order>, it should inject Repository<Order> ?!

[Export(typeof(IRepository<>))]
public class Repository<T> : IRepository<T>
{
}

In fact MEF only knows there is an export Repository<T> which is NOT the required one! And this is not the only question! Attentive reader will also observe the the contract type (which is a string) of the given export will be ‘SomeCleverNamespace.IRepository()’ which is an open generic. But the import’s contract type will be ‘SomeCleverNamespace.IRepository(SomeOtherCleverNamespace.Order)’ which is a closed generic. So even though MEF somehow knew the export Repository<Order>, the contract types wouldn’t match resulting in ImportCardinalityMismatchException.

The answer to the first question is on the fly export creation. Earlier I have introduced the concept of mapping contract type to its implementation(s). So when we import IRepository<>, MEF knows its implementation is Repository<>. But of course we import closed generic, like I said IReposiotry<Order>, so MEF knows the implementing type is Repository<Order>. Of course there is no export Repository<Order>, only Repository<T>. So it have to be introduced in runtime! This is where IExportHandler comes to play. The open generics support is all implemented in the GenericExportHandler class which is responsible for creating closed generic exports on the fly.

Finally, the answer to the second question is part rewriting. When we create Repository<Order> export on the fly (I mean in runtime), the export’s contract type will remain ‘SomeCleverNamespace.IRepository()’. So we have to rewrite the part so that the contract type and optionally contract name will be set properly. To do the part rewriting, special catalog is used – GenericTypeCatalog. It accepts two types – the concrete type being exported (e.g. Repository<Order>) and the open-generic contract type (e.g. IRepository<>). What the catalog does in its internals is to rewrite all open-generic exports which match the contract type to be closed-generic. In our example, the contract type will be rewritten from ‘SomeCleverNamespace.IRepository()’ to ‘SomeCleverNamespace.IRepository(SomeOtherCleverNamespace.Order)’. Same for contract name.

Meet the IExportHandler interface

The purpose of this interface is to filter out exports based on any criteria you want, as well as to dynamically create new exports. Let’s have a look at the IExportHandler signature.

public interface IExportHandler
{
  void Initialize(ComposablePartCatalog interceptedCatalog);

  IEnumerable<Tuple<ComposablePartDefinition, ExportDefinition>>
      GetExports(
          ImportDefinition definition,
          IEnumerable<Tuple<ComposablePartDefinition,ExportDefinition>> exports);
}

Wow! This looks complicated! Hopefully, it is not :) The initialize method gets called once when the export handler is initialized. Within this method you get a reference to the catalog being intercepted. The main player here is the GetExports method which has the exact same signature as the GetExports method in the ComposablePartCatalog class. It is called whenever an InterceptingCatalog is asked for exports which match the given import. The import definition is passed as the first argument. The second argument is a collection of matching export definitions along with theirs ComposablePartDefinition instances. The initial collection is the collection of exports from the intercepted catalog. Because the method returns the collection of matching exports, we can filter out the original exports we don’t want to show up, or what is more interesting, we can add our own export definitions!

Known limitations

Although support for open-generics in MefContrib is pretty amazing, it is not perfect. The first and probably the biggest limitation is the lack of support for recomposition. The other problem is that type being imported is inferred from the language construct rather than the import itself. Consider the following two imports.

[Import]
public IRepository<Order> OrderRepository { get; set; }

[Import(typeof(IRepository<Order>))]
public object OrderRepository { get; set; }

Both imports are perfectly legal. But only the former works as expected. This is because the type being imported is inferred from the property’s type, which is IRepository<Order>. In the latter example, the contract type is explicitly given in the Import attribute, but the property’s type is object, hence the inferred type will be object, which is not the case. You may want to know why is that. As you probably know, the import in MEF is represented by the ImportDefinition class. Unfortunately, it is NOT possible to get the Type instance representing the import from the ImportDefinition instance, only the defining construct (like property, field, etc.) and only for those ImportDefinition instances created by MEF’s Reflection Model.

Conclusion

In this post I have presented MefContrib’s approach to enable open-generic type composition. Hope you like it!

MEF Deep Dive Talk

noreply@blogger.com (Piotr Włodek) — Tue, 14 Dec 2010 22:36:00 +0000

Recently, I gave 2 talks about Managed Extensibility Framework. One on KGD.NET, which is our local .NET group (on Nov 24th 2010), and one on IT Academic Day at Uniwersytet Jagielloński in Kraków (Dec 14th 2010). Both of my talks went good! I do enjoy spreading knowledge about MEF and MefContrib! When it comes to the presentations, both were mostly the same, although on ITAD I was speaking more about MEF itself and less about hard stuff, so it was kind a MEF Deep Dive Light Edition =) I covered the following:

Basics of developing loosely coupled components
MEF basics (parts, exports, imports, composition)
Catalogs
Metadata
Custom export attributes
Recomposition
Stable composition
Debugging MEF
MefContrib
MEF Extensibility

You can find all the materials (slides + source code) from the KGD.NET meeting here and from the ITAD here. If you haven’t attended any of the talks, you might still want to go through the slides (these are nice!) and run the demos (VS 2010). Finally, I want thank Mike Taulty for letting me use some of the slides from his MEF talk =)

MatrixAnimation for WPF

noreply@blogger.com (Piotr Włodek) — Sat, 04 Dec 2010 18:22:00 +0000

Windows Presentation Foundation has a powerful animation system. It comes with various classes which enable dependency properties’ values to be animated, i.e. to be automatically changed during a given period of time. WPF supports four types of animations:

Linear animation – a value of a property linearly changes from a starting value (referred as From) to a destination value (referred as To).
Key frame animation – animation is specified using key frames, each key frame specifies the time and the desired value. The animated property will be assigned once the timeline hits the give time.
Path-based animation – property value is given by a geometric path.
Frame-based animation – this is the most powerful animation approach, the CompositionTarget class is used to create custom animations based on a per-frame callback.

The first three animation types are supported by <Type>Animation, <Type>AnimationUsingKeyFrames and <Type>AnimationUsingPath classes, respectively. For example, consider the double type. Its animation is supported by DoubleAnimation, DoubleAnimationUsingKeyFrames and DoubleAnimationUsingPath classes.

WPF also supports matrix animations. However, out of the box, only key frame and path-based animations are supported for the Matrix type. This post introduces MatrixAnimation class, which performs linear, smooth animation of the Matrix type. The animation supports translation, scaling and rotation along with easing functions. The following 14 sec-length video shows an early preview of a multi-touch MDI interface whose windows are being animated using the MatrixAnimation class.

The following code snippet represents the MatrixAnimation class.

public class MatrixAnimation : MatrixAnimationBase
{
    public Matrix? From
    {
        set { SetValue(FromProperty, value); }
        get { return (Matrix)GetValue(FromProperty); }
    }

    public static DependencyProperty FromProperty =
        DependencyProperty.Register("From", typeof(Matrix?), typeof(MatrixAnimation),
            new PropertyMetadata(null));

    public Matrix? To
    {
        set { SetValue(ToProperty, value); }
        get { return (Matrix)GetValue(ToProperty); }
    }

    public static DependencyProperty ToProperty =
        DependencyProperty.Register("To", typeof(Matrix?), typeof(MatrixAnimation),
            new PropertyMetadata(null));

    public IEasingFunction EasingFunction
    {
        get { return (IEasingFunction)GetValue(EasingFunctionProperty); }
        set { SetValue(EasingFunctionProperty, value); }
    }

    public static readonly DependencyProperty EasingFunctionProperty =
        DependencyProperty.Register("EasingFunction", typeof(IEasingFunction), typeof(MatrixAnimation),
            new UIPropertyMetadata(null));

    public MatrixAnimation()
    {
    }

    public MatrixAnimation(Matrix toValue, Duration duration)
    {
        To = toValue;
        Duration = duration;
    }
        
    public MatrixAnimation(Matrix toValue, Duration duration, FillBehavior fillBehavior)
    {
        To = toValue;
        Duration = duration;
        FillBehavior = fillBehavior;
    }

    public MatrixAnimation(Matrix fromValue, Matrix toValue, Duration duration)
    {
        From = fromValue;
        To = toValue;
        Duration = duration;
    }
        
    public MatrixAnimation(Matrix fromValue, Matrix toValue, Duration duration, FillBehavior fillBehavior)
    {
        From = fromValue;
        To = toValue;
        Duration = duration;
        FillBehavior = fillBehavior;
    }

    protected override Freezable CreateInstanceCore()
    {
        return new MatrixAnimation();
    }

    protected override Matrix GetCurrentValueCore(Matrix defaultOriginValue, Matrix defaultDestinationValue, AnimationClock animationClock)
    {
        if (animationClock.CurrentProgress == null)
        {
            return Matrix.Identity;
        }

        var normalizedTime = animationClock.CurrentProgress.Value;
        if (EasingFunction != null)
        {
            normalizedTime = EasingFunction.Ease(normalizedTime);
        }

        var from = From ?? defaultOriginValue;
        var to = To ?? defaultDestinationValue;

        var newMatrix = new Matrix(
                ((to.M11 - from.M11) * normalizedTime) + from.M11,
                ((to.M12 - from.M12) * normalizedTime) + from.M12,
                ((to.M21 - from.M21) * normalizedTime) + from.M21,
                ((to.M22 - from.M22) * normalizedTime) + from.M22,
                ((to.OffsetX - from.OffsetX) * normalizedTime) + from.OffsetX,
                ((to.OffsetY - from.OffsetY) * normalizedTime) + from.OffsetY);

        return newMatrix;
    }
}

The code is actually quite simple. The class is derived from the abstract MatrixAnimationBase class. Firstly, three dependency properties are defined, namely From, To and EasingFunction. Next comes a bunch of useful constructors. The interesting part resides in the GetCurrentValueCore method. At first, the current animation time is retrieved. Also, the animation time is eased with the easing function if it is available. Lastly, new matrix is calculated based on the From and To values. Each matrix cell is linearly scaled with the time value. And that’s it! This provides smooth animation for the matrix type!

Introduction to InterceptingCatalog – Part I

noreply@blogger.com (Piotr Włodek) — Tue, 09 Nov 2010 20:16:00 +0000

Managed Extensibility Framework uses the concept of catalogs. A single catalog is responsible for providing access to parts, which are mostly components in the system (ordinary .NET classes). I said mostly because MEF is not limited to operating on types, it also supports method, property and field composition. The catalog is then used by the CompositionContainer to pull parts from it. Out of the box MEF ships with 4 core catalogs, which are meant to discover attributed parts (an attributed part is simply a component which uses attributed programming model for discovery purposes). These catalogs are TypeCatalog, DirectoryCatalog, AssemblyCatalog, and AggregateCatalog. Catalogs serve one other crucial purpose – they are responsible for instantiating parts. The thing is that the underlying infrastructure (aka Reflection Model) responsible for that process is hidden from the developer and it is not possible to attach anything to the creation pipeline. People who just begin their MEF adventure might feel a little disappointed at first, because all of the IoC containers available today provide neat infrastructure for integrating custom build strategies into the creation pipeline. Furthermore, some of them, support interception out of the box (like the Unity container from MS Patterns & Practices).

The InterceptingCatalog, initially written by Glenn Block, has been introduced to fix this gap. It provides a convenient mechanism which allows to intercept values exported via MEF, it allows to chain interceptors together to form custom instance processing pipeline (Chain of Responsibility design pattern). The catalog also enables to create exports on the fly (which is used to provide open-generics support for MEF) and to filter existing exports based on some criteria. The catalog itself has been built around the Decorator pattern – it decorates any ComposablePartCatalog. You can find it in the MefContrib project available at mefcontrib.com.

In this series of posts I am going to discuss all the benefits of using the InterceptingCatalog. In the first part I will focus on intercepting capabilities of the catalog, and in subsequent posts I will cover filtering scenario and show how to enable the open-generics support.

Interception

Let’s begin with a simple example and then build on top of it. Assume we have IStartable interface defined as follows:

public interface IStartable
{
   bool IsStarted { get; }

   void Start();
}

We want every component, which implements the IStartable interface, have its Start method automatically called by the IoC container as part of the creation process. First, lets investigate the solution on the Unity IoC example. Note that the interception term does not apply to the Unity solution as the Unity fully supports custom build strategies =)

public class MyExtension : UnityContainerExtension
{
   protected override void Initialize()
   {
       Context.Strategies.AddNew<StartableStrategy>(UnityBuildStage.Initialization);
   }

   public class StartableStrategy : BuilderStrategy
   {
       public override void PreBuildUp(IBuilderContext context)
       {
           var instance = context.Existing as IStartable;
           if (instance != null)
           {
               instance.Start();
           }
       }
   }
}

The code is dead simple. We define our own extension named MyExtension, which does nothing more than registering the StartableStrategy during the instance initialization phase. The inner StartableStrategy does all the job - if the instance being created implements IStartable, it calls its Start method. The usage is also pretty straightforward. All we have to do is to add MyExtension to the container!

IUnityContainer container = new UnityContainer();
container.AddNewExtension<MyExtension>();

var foo = container.Resolve<StartableFoo>();
Console.WriteLine(foo.IsStarted); // Prints True

Assuming that the StartableFoo part implements the IStartable interface, it will have its Start method called during the Resolve method call. Now let's look at how this scenario could be implemented in MEF. As I stated previously, MEF doesn't allow the developer to register custom build strategies within the build process. Hence, we need to use interception. This is where the InterceptingCatalog comes to play. To use the InterceptingCatalog, we first need to create proper configuration. The configuration is provided by means of InterceptionConfiguration class:

public class InterceptionConfiguration : IInterceptionConfiguration
{
   public InterceptionConfiguration AddInterceptor(IExportedValueInterceptor interceptor);
   public InterceptionConfiguration AddHandler(IExportHandler handler);
   public InterceptionConfiguration AddInterceptionCriteria(IPartInterceptionCriteria partInterceptionCriteria);
}

In this example we are interested in the AddInterceptor and AddInterceptionCriteria methods which add interceptors to the catalog. The two methods correspond to two interception levels supported by the catalog. The first is the catalog wide interception level. Interceptors registered on this level are applied to all parts available in the decorated catalog. The second level is the per part interception level. Interceptors registered on that level apply only to selected parts, and the developer specifies to which parts the interceptor should be applied by specifying a predicate which accepts ComposablePartDefinition and returns bool. Next example will show this in action. Meanwhile, this is how our StartableStrategy might look like:

public class StartableStrategy : IExportedValueInterceptor
{
   public object Intercept(object value)
   {
       var startable = value as IStartable;
       if (startable != null)
       {
           startable.Start();
       }

       return value;
   }
}

As you can see, all interceptors have to implement the IExportedValueInterceptor interface, which defines single Intercept method. The method gets called as soon as the exported value is requested, and the value itself is passed as the parameter. To demonstrate the usage, we will use two parts, namely IFoo and IBar. The IBar part is defined as follows:

public interface IBar
{
   void Foo();
}

[Export(typeof(IBar))]
public class Bar : IBar, IStartable
{
   public Bar()
   {
       Console.WriteLine("Bar()");
   }

   public bool IsStarted { get; private set; }

   public void Start()
   {
       IsStarted = true;
       Console.WriteLine("Bar.Start()");
   }

   public void Foo()
   {
       Console.WriteLine("Bar.Foo()");
   }
}

The code which uses the StartableStrategy is also very simple.

// Create the catalog which will be intercepted
var catalog = new TypeCatalog(typeof(Bar), typeof(Foo));

// Create interception configuration
var cfg = new InterceptionConfiguration()

   // Add catalog wide startable interceptor
   .AddInterceptor(new StartableStrategy());

// Create the InterceptingCatalog with above configuration
var interceptingCatalog = new InterceptingCatalog(catalog, cfg);
          
// Create the container
var container = new CompositionContainer(interceptingCatalog);

var barPart = container.GetExportedValue<IBar>();

Because the IBar part implements the IStartable interface, it will have its Start method called as part of GetExportedValue call. This example concludes the basics of using InterceptingCatalog. Lets move on to the next interception example which uses Castle.DynamicProxy to create proxies for objects. We will add logging capabilities to the IFoo part. We do not want to log method execution on the IBar part, so we are going to leverage the per part interception. The IFoo part looks identical to the IBar part, except it is decorated with ExportMetadata attribute, which tells the system that we want to log method execution on that part.

public interface IFoo
{
   void Bar();
}

[Export(typeof(IFoo))]
[ExportMetadata("Log", true)]
public class Foo : IFoo, IStartable
{
   public Foo()
   {
       Console.WriteLine("Foo()");
   }
      
   public bool IsStarted { get; private set; }

   public void Bar()
   {
       Console.WriteLine("Foo.Bar()");
   }

   public void Start()
   {
       IsStarted = true;
       Console.WriteLine("Foo.Start()");
   }
}

Next comes the logging interceptor which implements Castle's IInterceptor interface.

public class LoggingInterceptor : IInterceptor
{
   public void Intercept(IInvocation invocation)
   {
       Console.WriteLine("--- LOG: About to invoke [{0}] on [{1}] ---",
           invocation.Method.Name,
           invocation.InvocationTarget.GetType().Name);

       // Invoke the intercepted method
       invocation.Proceed();
          
       Console.WriteLine("--- LOG: Invoked [{0}] ---", invocation.Method.Name);
   }
}

The interceptor simply prints information to the console before and after a method execution. The code which puts this sample together is almost a copy of the previous bootstrapping code:

var catalog = new TypeCatalog(typeof(Bar), typeof(Foo));

// Create interception configuration
var cfg = new InterceptionConfiguration()

   // Add Castle DynamicProxy based logging interceptor for parts
   // which we want to be logged
   .AddInterceptionCriteria(
       new PredicateInterceptionCriteria(
           new DynamicProxyInterceptor(new LoggingInterceptor()), def =>
               def.ExportDefinitions.First().Metadata.ContainsKey("Log") &&
               def.ExportDefinitions.First().Metadata["Log"].Equals(true)));

// Create the InterceptingCatalog with above configuration
var interceptingCatalog = new InterceptingCatalog(catalog, cfg);
          
// Create the container
var container = new CompositionContainer(interceptingCatalog);

var barPart = container.GetExportedValue<IBar>();
barPart.Foo();

var fooPart = container.GetExportedValue<IFoo>();
fooPart.Bar();

Because we wanted to apply the logging interceptor on a per part basis, we use the AddInterceptionCriteria method, and pass the PredicateInterceptionCriteria instance. The PredicateInterceptionCriteria object takes any instance implementing the IExportedValueInterceptor interface along with a predicate which is used to determine which parts should be intercepted with the given interceptor. In the above example we intercept all parts declaring Export metadata named Log which equals to True. Note that our logging interceptor is based on Castle.DynamicProxy. To use it with the catalog, we need to wrap it with DynamicProxyInterceptor which implements IExportedValueInterceptor and can take any number of IInterceptor implementations. The sample produces the following output:

You can see that indeed the logging interceptor has only been applied to the IFoo part. Please note also that the IFoo has actually been intercepted by a chain of two interceptors, the StartableStartegy and the LoggingInterceptor (although the above sample code omits the first one for clarity). This forms a processing pipeline similar to pipelines found in regular IoC containers. This is all about interception in MEF. You can download sample code from my code gallery here. In the next post I will look at filtering capabilities. Stay tuned!

MEF + Object Factories using Export Provider

noreply@blogger.com (Piotr Włodek) — Sat, 16 Oct 2010 18:50:00 +0000

MEF is a great composition platform. It is great because the power and flexibility it delivers, and at the same time, the learning curve is low. When it comes to part registration, MEF out of the box supports so called attributed programming model, which allows the discoverability simply by applying Export attributes on the parts we want to make available to the world, and Import attributes on the parts which need to consume other parts. However, using this default programming model, the developer has no way of introducing any build strategies which get executed during part’s creation when a concrete part is requested. This concept, know as Chain of Responsibility design pattern, is implemented by many (if not all) dependency injection containers. Most of them allow the developer to add new actions which are executed as part of object creation. Sadly enough, there’s no such facility in MEF. This implies yet another limitation – lack of support for custom object factories. This means it is always MEF who creates parts’ instances.

Luckily, MEF is extensible. It allows to develop completely new programming models by implementing custom catalogs (like the ConventionCatalog which is a part of MefContrib). It also enables the developers to implement custom export providers, whose role it to provide exports from various sources =) In this post I am going to introduce the FactoryExportProvider which extends MEF by allowing to define object factories.

Introducing Custom Factories

When you want co take control over instance creation in MEF, you basically have two options. Either create part manually and then call ComposeExportedValue method on that part as presented on the following listing

var component = new ExternalComponent2();
container.ComposeExportedValue(component);

or use property export as presented below.

[Export]
public IExternalComponent Component1
{
  get
  {
      return new ExternalComponent3(/* Constructor Initialization */);
  }
}

The first solution, however, is not very elegant. It also registers new part as singleton. The second one is better, but still the part will be created only once, and reused across many requests. Also note that in both solutions, a problem arises when it comes to injecting target part’s constructor – we don’t have access to the container so we can’t pull required parts from it. Of course we could get a reference to the container, but doing so only for this purpose will make the code more sloppy.

Meet FactoryExportProvider

The FactoryExportProvider is an elegant solution to the outlined problems. Consider the following sample code:

var provider = new FactoryExportProvider()
  .RegisterInstance<IExternalComponent>(ep => new ExternalComponent2())
  .Register<IExternalComponent>("part4", ep => new ExternalComponent4(
                                                  ep.GetExportedValue<IExternalComponent>(),
                                                  ep.GetExportedValue<IMefComponent>()));

var container = new CompositionContainer(anyCatalog, provider);
provider.SourceProvider = container;

You can clearly see two parts being registered, both with the same interface. The first one is registered as a singleton (shared in MEF), but more interestingly, the second is registered as transient (non shared in MEF) and will be created each time the part is requested. As part of the registration process, a factory method should be passed (this is not required, read on to find out why) which is responsible for delivering instances. Note also an elegant, though widely adapted, solution to resolving complex constructors. In the example, the ExternalComponent4 has a dependency on IExternalComponent and IMefComponent parts. However, thanks to the fact that the resolution method has access to the source provider (ExportProvider instance), we can use it to satisfy additional imports. Just remember to set SourceProvider property of the FactoryExportProvider to something meaningful (at least to the FactoryExportProvider instance itself as the SourceProvider is null by default). More common is to set it to the CompositionContainer instance.

FactoryExportProvider is quite flexible. It allows to register a fallback factory method which gets executed whenever part is registered without supplying the factory method enabling to design single resolution method for a subset or all parts registered in the factory. See the following example.

private static object FactoryMethod1(Type type, string registrationName)
{
  if (type == typeof(IExternalComponent) && registrationName == null)
      return new ExternalComponent1();

  if (type == typeof(IExternalComponent) && registrationName == "external2")
      return new ExternalComponent2();

  return null;
}

var provider = new FactoryExportProvider(FactoryMethod1);
var container = new CompositionContainer(someCatalog, provider);

// Registration
provider.Register(typeof(IExternalComponent));
provider.Register(typeof(IExternalComponent), "external2");

The code presented in this post is available as part of MefContrib Project. Latest version is available on my fork. In the coming days I will push it to the main repo though! This export provider is also used by IoC plumbing infrastructure, which is also part of MefContrib Project, which enables integration of IoC and MEF. I blogged about particular implementations for Unity container here and here.

Hope you like it!

Git on Windows with Console and PowerShell

noreply@blogger.com (Piotr Włodek) — Sat, 04 Sep 2010 17:19:00 +0000

Windows people like to do everything on their computers using GUI tools and WYSIWYG editors. And nothing is wrong with that. Personally, I like this approach – it conserves time while giving fast access to the most used options of a given tool (at least usually). Consider the SVN version control system. Initially, it was a console-based tool, but thanks to the great TortoiseSVN project, people may now forget about the command line. However, working with Git is different. Git was designed to be used from the command line, and using it in that way is a pure pleasure! Git commands are well crafted and easy to remember. If you are holding out on Git because it doesn’t give you the right GUI tools, you are holding out for a wrong reason.

Git comes with a bash like prompt which is very powerful. However, there is one problem. The bash prompt is launched within the standard Windows command line, and as probably anyone knows, the command prompt on Windows is one, big misery. So in this post I’m going to address this issue by showing how to set up a convenient command line environment for Git on Windows.

Installing Git

Git can easily be installed on Windows. Head over to http://code.google.com/p/msysgit/ and download Git-1.7.0.2-preview20100309.exe which is the latest version of Git as of this writing. When the installer asks about [Adjusting the PATH environment], select [Run Git from the Windows Command Prompt] as shown on the following screen.

Selecting this option allows to use Git from different shells, like PowerShell. Now that Git is installed, we can open a command line and verify it’s there.

We can also right click any folder in the Windows Explorer and select Git Bash Here – this will launch Git’s default bash shell.

Installing Console

Now it’s time to get rid of the ugly prompts shown above. Head over to the http://sourceforge.net/projects/console/ and download the latest version of the Console project. Launch it, and go to Edit->Settings, select Console from the tree on the left and pick up a new shell – the PoweShell. Under Windows 7/2008, it is located at %Windows_Dir%\System32\WindowsPowerShell\v1.0\powershell.exe. On previous versions of Windows, I believe it must be downloaded separately. Click OK and close the Console. Now launch it again, but this time with Administrator privileges, and issue the following command: [Set-ExecutionPolicy Unrestricted]. This command will allow running custom PowerShell scripts, which is needed for Git integration. Now you have a working PowerShell within nice, tabbed environment. We’re almost there!

Installing PoshGit

It’s time to enable PowerShell-Git integration. To do that, download Posh-Git latest sources available at http://github.com/dahlbyk/posh-git and unpack them to %Sys_Drive%:\Users\%Login%\Documents\WindowsPowerShell. Change profile.example.ps1 to profile.ps1. Hurray! You have enabled Git integration! What does it give? When you are inside Git repository, the command prompt changes to show on which branch you are, and whether there are any modifications, and if there are any untracked files (via exclamation mark). To enable output coloring, issue the [git config –global color.ui auto] command.

Enjoy your cool, command line interface for Git!

Sharp3D – The Beginning

noreply@blogger.com (Piotr Włodek) — Thu, 02 Sep 2010 19:06:00 +0000

Back when I was on holidays, I’ve read a post by Maciej Aniserowicz about the “Daj się poznać” contest. The aim of the contest is to write an open source project of any kind in any technology, and blog about it at least twice a week, for ten weeks period. There’s also pretty nice collection of software to win. And because a crazy idea is floating in my head for a while, I thought – why don’t give it a try?

So what am I going to create? I’m going to build a research application for manipulating 3D objects, perhaps with the ability to define materials for them, modify existing objects, add new objects to the scene, and render them using custom crafted raytracing algorithm. As if this were not enough, application will fully support multi-touch displays.

Currently, I have a basic skeleton of the application, with my own scene objects (I want to abstract from WPF elements). Here’s the screenshot from the initial drop.

Motivation

There are a couple of reasons I’m writing this project. By no means, the most important thing for me is to learn strong basics of 3D programming. Triangles, tessellation, normals, materials, lightning, raytracing and more – there is a whole bunch of 3D stuff to master. I also want to learn this in context of WPF 3D – hope this will help me in building better looking apps in the future. I also want to see if the WPF 3D is suitable for project which does more than displaying 3D cubes with buttons on the sides. And last but not least – 3D programming is fun!

Goals

I want Sharp3D to be an extensible foundation for writing 3D applications by others. Thus, the main goal is the extensibility and component design. The application will span several components which can be used in standalone manner – this will support others in developing their own 3D applications! I want to provide many ways of interacting with the 3D model. So besides the standard mouse and keyboard, I will utilize multi-touch capabilities of today’s monitors, and the Wiimote. Because editing capabilities, if any, will be very limited, an important part is to write a loader which will take existing scene and import it to the program. I plan to implement 3ds file importer, because this is de facto the standard in the 3D industry – all known modeling applications support it. Having that, another cool feature will be XAML exporter.

Tools

Because this is a research project, I’m going to use the latest and greatest tools available J This includes:

· .NET Framework 4.0

· Visual Studio 2010

· WPF 4.0

· Blend 4.0

· Git

· Multi-touch / Wiimote

Sources

I decided to use Git which is a fast, distributed version control system. The distributed means that the code repository lives not only on the server (which by the way is not a requirement) but on the user’s computer. This allows committing changes locally, and then pushing them back to the server. When using Git, the natural choice for open source repository is GitHub. The Sharp3D sources can be found at http://github.com/pwlodek/Sharp3D.

There are two important branches. The most important is the master branch. It will contain, latest, stable version. The development will be done on the dev branch. Besides, I will try to use the branch-per-feature approach, which I presume is self-explanatory. After I decide a feature is complete, it will be merged into dev branch, and then into master.

Contribution

If you are interested in contributing to the project – you are more than welcome! Just drop me an email so we can discuss the details. To begin your contribution, register on GitHub and fork the main repo and work on your part. Once ready, issue a pull request – and I will do the rest ;) The one thing is that I won’t pull till the end of the contest as the participants are supposed to work on their own.

Lazy<T> and IEnumerable<Lazy<T>> support comes to Unity

noreply@blogger.com (Piotr Włodek) — Thu, 13 May 2010 18:10:00 +0000

If you are familiar with .NET Framework 4.0 or Managed Extensibility Framework, you probably know that there's a type called Lazy<T> which enables lazy instantiation. This type comes in handy when used with any form of dependency injection. Instead of injecting a concrete instance of a service or whatever you want, you can inject instance which wraps the requested type and instantiates it only when the program really needs to use it. Consider the following code which uses - guess what - MEF =)

[Export]
public class Account
{
[Import]
public Lazy<ILogger> Logger { get; set; }

public void Deposit(decimal amount)
{
if (amount < 0)
{
  Logger.Value.Log("Amount is less than 0.");
}
}
}

Here you can see a fragment of an Account class implementation which has an ILogger instance injected in lazy manner. As long as the Deposit method is not invoked with a value less than 0, the logger instance is not used, thus, it is actually not created at all! Lazy instantiation is particularly usefull when you are dealing with objects which are expensive to create.

There are some IoC containers which support Lazy<T> out of the box, namely Autofac 2, or Managed Extensibility Framework to name a few (I don't like calling MEF an IoC container, it's rather a composition engine since it is not constrained to inject types, but methods, fields and properties as well - sorry for that). Unfortunately, Unity IoC (even the latest Unity 2.0) is not on that list. Yes, I know. Unity 2.0 has a support for a concept known as automatic factories (you can read more on that here). Basically speaking, automatic factories allow to pull Func<T> - which is a delegate to a function which returns the concrete instance of the requested component when called. The idea is to fire this delegate when the instance is really needed. So you can say this serves the same purpose as Lazy<T>. Yeah, but it is not Lazy<T> ;) Besides, having the ability to pull Lazy<T> enables even better usage of the Unity+MEF integration layer, which is a part of MEF Contrib initiative. You can always find lates sources hosted on github.

OK. How to leverage the Lazy<T> and IEnumerable<Lazy<T>> ? This is a piece of cake. There are three ways of using the extension. If you want to pull a single component, here's how to do that:

unityContainer.RegisterType<IComponent, Component1>();
var lazyComponent = unityContainer.Resolve<Lazy<IComponent>>();

If you want to pull all components registered under a common type, you can do the following:

unityContainer.RegisterType<IComponent, Component1>("component1");
unityContainer.RegisterType<IComponent, Component2>("component2");
unityContainer.RegisterType<IComponent, Component3>();

// A collection of non-lazy components
var collectionOComponents = unityContainer.Resolve<IEnumerable<IComponent>>();

// Lazy collection of components, once resolved, all the components get resolved
var lazyCollectionOfComponents = unityContainer.Resolve<Lazy<IEnumerable<IComponent>>>();

// Concrete collection of lazy loaded components
var collectionOfLazyComponents = unityContainer.Resolve<IEnumerable<Lazy<IComponent>>>();;

One thing to note. Resolving an IEnumerable is not the same as calling ResolveAll! ResolveAll returns only named types, whereas IEnumerable returns everything!

Either way, before you can use anything presented so far, you have to add the extension the the container. It is as simple as calling:

unityContainer.AddNewExtension<LazySupportExtension>();

An important, and nice thing as well, is that the presented stuff is already the part of MEF Contrib. If you use MEF+Unity integration layer, you automatically get this behavior out of the box!

The code sample can be downloaded, as always, from my code gallery here. Enjoy!

MEF Contrib for Silverlight 3 (Unofficial)

noreply@blogger.com (Piotr Włodek) — Tue, 24 Nov 2009 21:55:00 +0000

I’m happy to announce that I’ve completed porting the most recent MEF Contrib (0.7) project to SL3. The project has also been updated to use the most recent MEF release which is beta 2 (Preview 8) as of this writing. All the unit tests from the project pass in the SL environment, here are the screenshots:

Before I dig into the changes I had to make in order to make it work on SL3, I will focus on NUnit for SL.

As all of you probably know, it is possible to run NUnit tests in SL environment. Microsoft has released a library called Microsoft.Silverlight.Testing which enables developers to execute tests on SL’s CLR. This library ships out of the box with the implementation of MS Tests. However, its extensibility allows to write custom providers for other testing frameworks. Jeff Wilcox wrote a post about running NUnit tests in the SL environment here. He did two things: ported a subset of NUnit to SL, and wrote a provider which enables running NUnit tests using Microsoft.Silverlight.Testing framework. However, his NUnit implementation is very limited, so I googled a little and found a guy who ported NUnit 2.5.1 to SL (you can find his post here). So, for the testing purposes I used mentioned NUnit 2.5.1 SL port together with a provider developed by Jeff. I must admit here, that I’m not sure whether all the features from NU 2.5.1 work correctly in the SL environment. Hopefully, it seems that all the Assert methods including Assert.That and Throws work as expected.

As far as MEFContrib project is concerted, I didn’t have to introduce many modifications. MefContrib.Extensions.Generic project runs without any changes. MefContrib.Integration.Unity project didn’t need to be changed in terms of its implementation. However, all stubs used in unit tests were declared as internal, and it seems MEF for SL has some troubles while instantiating non public members (or SL policy doesn’t allow this?) so most tests were failing. Fortunately, changing access to public repaired everything :) The story is a bit different for the MefContrib.Models.Provider project. This project adds to MEF custom provider model with three programming models built on top of it. These three programming models are

Attributed – as it name suggest, parts are registered using attributes,
Configurable – parts get registered via App.config,
Fluent – parts are registered through method invocation.

The problem lays in the Configurable programming model, because it is implemented using System.Configuration namespace, which is not available to SL programmers. Thus, MefContrib.SIlverlight does not support this model.

The last trouble I had was with two test, which reside in MemberInfoServicesTests test fixture, namely

GetMemberInfoShouldReturnMemberIfMemberNameIsSupplied,
GetMemberInfoShouldReturnTypeIfMemberNameNotIsSupplied.

Both unit tests test MemberInfoServices class. Both were throwing an exception telling that the test assembly (MefContrib.Models.Provider.Tests) cannot be loaded or the assembly has already been loaded but the versions doesn’t match. To cut the long story short, it turned out that the following code was the root cause (code like the presented below is executed in MemberInfoServices.GetMemberInfo method in both tests) :

Type.GetType("MefContrib.Models.Provider.Tests.FakePropertyPart, MefContrib.Models.Provider.Testsl", false, true)

Don’t know why this doesn’t work. However, a simple modification like follows did the job :)

Type.GetType("MefContrib.Models.Provider.Tests.FakePropertyPart, MefContrib.Models.Provider.Tests, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null", false, true)

To maintain separate versions of both tests for regular CLR and SL, I used SILVERLIGHT compiler flag.

Please note that this version is an unofficial release, not available through codeplex.com site. However, I will put an effort to make this an official release or make next MefContrib release based on this one.

Full source code is available on my code gallery here.

Watermark effect for WPF’s TextBox and ComboBox controls

noreply@blogger.com (Piotr Włodek) — Sat, 21 Nov 2009 16:31:00 +0000

Update

I have updated this sample to contain the watermark effect for the ComboBox control too. Its implementation is almost identical to the TextBox’s one. Here are the screens showing the effect being applied to the ComboBox control:

And here comes the original post.

In this post I’m going to show a nice watermark effect for WPF’s TextBox control. Sample application (link to the sources at the end of this post) looks as follows:

As you can see, non focused text box containing no text, displays a useful clue to the user informing what kind of information should be entered. Focusing a textbox immediately removes that clue.

There are probably as many ways to introduce such a behavior as there are developers all over the world :) However, one particular solution is to be considered in this case. The above effect has been achieved using adorners. The adorner used for the effect contains a single TextBlock with optional style applied to it. A good introduction to adorners is available here.

The effect has been implemented using attached behavior pattern, so no inheritance was introduced.

Using the behavior is a piece of cake. Here’s how to apply the behavior to a TextBox control:

<TextBox Height="25" Margin="0,5,0,5"
Behaviors:WatermarkTextBoxBehavior.EnableWatermark="True"
Behaviors:WatermarkTextBoxBehavior.Label="Label"
Behaviors:WatermarkTextBoxBehavior.LabelStyle="{StaticResource watermarkLabelStyle2}" />

The first property, EnableWatermark, as its name suggests, enables the effect ;) The Label property holds the text to be displayed as a watermark. Finally, the LabelStyle property contains the style to be applied to the label. And the style, defined in Window’s Resources collection, might look as follows:

<Style x:Key="watermarkLabelStyle">
<Setter Property="TextBlock.Foreground" Value="{x:Static SystemColors.ControlDarkBrush}" />
<Setter Property="FrameworkElement.Opacity" Value="0.8" />
<Setter Property="TextBlock.FontSize" Value="12" />
<Setter Property="TextBlock.FontStyle" Value="Italic" />
<Setter Property="TextBlock.Margin" Value="8,4,4,4" />
</Style>

I’m not going to discuss any implementation details here since the adorner itself is trivial, and the behavior is quite easy as well. Maybe I will tell you that the watermark is displayed when the TextBox fires its Loaded event. Why is that important to know? Keep reading… ;P Besides, skim the code and you immediately know how stuff works :)

Finally, one thing, which deserves to give attention to, is control loading and the adorner layer (adorner layer is a place always rendered over the control where all adorners for that control get displayed). When a control is contained within a portion of UI that is being displayed, but the control itself is not visible, it normally fires Loaded event, but because it is not visible, it has no adorner layer! So don’t assume that call to AdornerLayer.GetAdornerLayer(Visual) always returns the adorner layer! This is why the sample shown above contains a TabControl – the second tab, named Tab 2, contains a TextBox with the watermark effect applied to it, and this still works :)

As always, code sample is available through my Code Gallery here.

Improved MEF + Unity Integration Layer

noreply@blogger.com (Piotr Włodek) — Sat, 22 Aug 2009 08:17:00 +0000

In my last post about Managed Extensibility Framework and Unity DI container I proposed a solution to make both frameworks work together in tandem, which in turn lets the developer leverage all the features from them at the same time. Now, the improved version is out, and it's a part of the MEFContrib project!

Having learned from developing the previous version, I decided to reimplement the integration layer from the ground up. The API changed very little, though ;)

The "biggest" change since the initial version is that you no longer need to provide boolean parameter during component registration in Unity to say that you want the component to be available to MEF. Now, this is done automatically using Unity container extension. So, the initialization of the layer now is super easy as it requires only single line of code :) Consider this:

// Setup
var unityContainer = new UnityContainer();
var aggregateCatalog = new AggregateCatalog();

// Register catalog and types
unityContainer.RegisterCatalog(aggregateCatalog);  // this call initializes the layer
unityContainer.RegisterType<IUnityOnlyComponent, UnityOnlyComponent1>();

The first call to RegisterCatalog method does the initialization - under the hoods, ComposiotionContainer is created, and a link between it and Unity is established. Pretty easy, huh ? :)

Next, all the types are public, so for example, if the standard RegisterCatalog method doesn't fit your needs, you can easily create your own using all the provided types as building blocks. The one concrete use case that comes to my mind is that the current implementation of the RegisterCatalog method does not allow you to attach any additional export providers (your own root CompositionContainer for instance) to the underlying CompositionContainer. In such a case, you can easily create separate method which accepts export providers and initializes the layer. Investigating RegisterCatalog method might be beneficial :)

One neat implication of having all types public is that you can now establish one-way synchronization, being MEF to Unity, in which Unity container knows about MEF parts and can resolve them, and Unity to MEF, in which MEF can pull Unity's components.

Finally, I've added support for closed generics, i.e. you can pull components from Unity and MEF using generics.

The usage of this layer is quite well described on MEFContrib wiki page.

Statically Typed Dependency Properties

noreply@blogger.com (Piotr Włodek) — Fri, 10 Jul 2009 20:59:00 +0000

Recently, I found a nice post written by a friend of mine, regarding statically typed property names. His post can be found here. What I simply did was to put his concept into WPF world :)

Problem

Typical registration of a WPF's dependency property looks like follows:

public int MyInteger1
{
get { return (int)GetValue(MyInteger1Property); }
set { SetValue(MyInteger1Property, value); }
}

public static readonly DependencyProperty MyInteger1Property =
DependencyProperty.Register("MyInteger1", typeof(int), typeof(Window1));

Hmm, what's wrong with it ? It "breakes" the DRY (Don't Repeat Yourself) principle. Given code defines a property named MyInteger of type int, but this information is coded twice, in the property itself and during its registration. If you want to change the name or type of a single property, you have to update the code in two places.

Solution

Now consider the following code:

public int MyInteger2
{
get { return (int)GetValue(MyInteger2Property); }
set { SetValue(MyInteger2Property, value); }
}

public static readonly DependencyProperty MyInteger2Property =
DependencyPropertyHelper.Register<Window1>(t => t.MyInteger2);

What has changed here is the way the property is registered. Now, changing the name or the type of a property is done through its getter. Nice, isn't it ? This approach works with both regular and read only properties but does not with attached properties, because the latter does not use property to access its value but uses methods instead. Implementation behind the Register<TOwner> method used above is fairly simple and looks like this:

public static class DependencyPropertyHelper
{
    public static DependencyProperty Register<TOwner>(
        Expression<Func<TOwner, object>> property)
    {
        return DependencyProperty.Register(typeof(TOwner).GetPropertyName(property),
                                           typeof(TOwner).GetPropertyType(property),
                                           typeof(TOwner));
    }
}

GetPropertyName and GetPropertyType methods come from the post I've mention at the beginning.

Full code can be downloaded from my code gallery.

WPF 3.5 (70-502) Exam Passed

noreply@blogger.com (Piotr Włodek) — Wed, 10 Jun 2009 16:36:00 +0000

Yesterday, I've successfully completed my first developer's certification by passing exam 70-502 TS: Microsoft .NET Framework 3.5 – Windows Presentation Foundation Application Development. My score was 921 out of 1000 which is also my personal best so far :)
I had 51 question, most of which were single choice, and 150 minutes to complete. Not all the questions were taken into account when computing the final score. Although I've chosen my questions in C#, I got one question in VB, so be prepared ;)

What can you expect from the exam as far as questions are concerned? Putting it simple, everything. Questions cover all the WPF' topics including WPF 3D, ClickOnce deployment, XPS and Flow documents, and Windows Forms interoperability.

As far as WPF 3D is concerned, the questions are rather easy and cover only the basics like cameras or meshes. If you are a novice, I recommend a brief reading about this subject (not because this appears on the exam, but because WPF 3D is a big fun). ClickOnce was heavily covered on the exam, so make sure you get your hands dirty playing with it. Besides basic knowledge, you should know how to download parts of the application on demand (parts which are not required for the application to run). Regarding flow documents, you should know what annotations are, how to manage them, display, persist, etc. Printing both flow and XPS documents is also covered on the exam, so brush up on this subject as well.

In my last words, I want to speak a little about books :) Generally, if you're already familiar with WPF, official Training Kit from MS is mostly sufficient, but it doesn't cover WPF 3D, and some subjects are touched rather briefly. But if you are at the very beginning, or if you simply want to broader you knowledge, I highly recommend picking up Adam Nathan's WPF Unleashed. Actually, if You are serious about WPF development, this book is a must read :)

Wish You good luck!

Unity + MEF Integration Layer

noreply@blogger.com (Piotr Włodek) — Sun, 24 May 2009 09:44:00 +0000

In this post, I’m going to discuss two of probable many solutions to the problem of making use of the Managed Extensibility Framework together with Microsoft’s Unity Application Block in an enterprise application. Presented solution combines the power of both frameworks, and exposes an intuitive and easy to use interface. If you are interested in putting MEF together with Unity, this post is definitely 4U. If you use Unity and want to get some basic knowledge about writing extension to it, you still might want to go briefly through the code, as the provided solution is based on the Unity Container Extensions (and MEF extensions as well). This post also assumes that you have a basic idea of Dependency Injection and how it relates to the design of an application. Basics of MEF will be helpful as well.
Divagations presented here are partially based on a great post titled Hosting MEF Extensions in an IoC Container by Nicholas Blumhardt, and I recommend you take a look at it before further reading this post :).

Problem

People around are sometimes/often confused about the role MEF plays in the world of the Dependency Injection – should MEF be treated as an Injection of Control solution, and thus should supersede it, or it is something else and should be used differently? Well, this is a little bit tricky question, but in what I understand, MEF is all about composition and robust components loading, thus is best suited for providing well-known extension (plug-ins) to the application, whereas IoC serves more as a backbone of an application, which is primary responsible for making all application’s internal modules work together. To sum up, MEF and Unity are very flexible and in many cases may be used interchangeably, but a general idea is that:

if you want to provide a plug-ins infrastructure so that 3rd parties were able to provide extensions for the app, use MEF (or Managed Add-in Framework + MEF if you want robust plug-in isolation :)),

if you want to structure your application’s architecture, use modules that are decoupled but with the ability to communicate, etc., use Unity or any existing IoC.

Solution 1

The first solution is pretty easy – simply use both frameworks independently of each other.

The definite plus of this approach is its ease of putting it into action in the application. But it has some drawbacks, mainly that MEF and Unity components can’t make use of each other. In other words, MEF component cannot contain any dependencies on Unity components that can be automatically satisfied via dependency injection. The same holds true for the Unity components, they simply cannot have dependencies on MEF components (note that by MEF component I mean component initially instantiated by MEF, and by Unity component I mean a component initially created by Unity container). Another drawback is that unity does know nothing about MEF, and vice versa. And why is that important ? Consider the following sample showing a dummy Presentation Model in presenter first approach (a typical scenario):

public class MyViewPresentationModel
{
public MyViewPresentationModel(IMyView view, IUnityService1 service1,
IMefComponent1 mefComponent1)
{
}
}

Note that in the constructor, I have both Unity service and MEF component, and because the MyViewPresentationModel class is instantiated via Unity and Unity knows nothing about IMefComponent1, this won’t work. But it should! Argh...

Although this solution is fairly simple to implement, it has several drawbacks that makes using it painful. So let’s go to the second :)

Solution 2

This solution uses a middle component, Unity + MEF Integration Layer (implemented as Unity.Integration.Mef.dll), which allows full interoperability between Unity and MEF, as you can see from the following figure.

As you can see, Unity is the backbone component, that uses the integration layer to communicate with MEF. In this solution, Unity components may have dependencies on MEF components, and vice versa. Of course, all dependencies will by injected automatically! So the following code will work (ICoreService is a Unity service whereas IMefService is instantiated by MEF):


public class CoreService2 : ICoreService
{
public CoreService2()
{
}

[Import("MefService3")]
private IMefService m_MefService3;

public void Foo()
{
}
}

What's even more important, with this approach, it's possible to mix components in the constructors, so the following both classes will work as well. Please note, that if you have a MEF component exported by name, you can reference it using the Unity's DependencyAttribute, and if you have a Unity component registered using a name, you can reference it in a MEF component using MEF's ImportAttribute ! :)

public class CoreComponent : (...)
{
 private readonly IMefService m_MefService3;
 private readonly ICoreService m_CoreService;

 // Interesting thing happens here: Unity injects components created
 // by both MEF and Unity
 public CoreComponent(
    [Dependency("MefService3")] IMefService mefService3,
    ICoreService coreService)
 {
    m_MefService3 = mefService3;
    m_CoreService = coreService;
 }

 [Import(AllowDefault = true)]
 private IEnumerable<imefservice> m_MefServices;

 public void FooBar()
 {
 }
}

[Export(typeof(IMefService))]
[PartCreationPolicy(CreationPolicy.Shared)]
public class MefService2 : IMefService
{
 private readonly IUnityContainer m_UnityContainer;
 private readonly ICoreService m_CoreService;

 // Interesting thing happens here: MEF injects components created
 // by both MEF and Unity
 [ImportingConstructor]
 public MefService2(IUnityContainer unityContainer,
    [Import("CoreService2")] ICoreService coreService)
 {
    m_UnityContainer = unityContainer;
    m_CoreService = coreService;
 }

 public void Bar()
 {
 }
}

Using the Unity + MEF Integration Layer is very simple, just reference Unity.Integration.Mef.dll in your project and you're almost done! Here's a sample:


// Create the Unity container and self-register
var unity = new UnityContainer();
unity.RegisterInstance<IUnityContainer>(unity);

// Register MEF catalogs in Unity
unity.RegisterCatalog(new AssemblyCatalog(Assembly.GetEntryAssembly()));
unity.RegisterCatalog(new DirectoryCatalog("."));

// Register unity components
unity.RegisterType<CoreComponent>();
unity.RegisterType<ICoreService, CoreService1>(new ContainerControlledLifetimeManager(), true);
unity.RegisterType<ICoreService, CoreService2>("CoreService2", new ContainerControlledLifetimeManager(), true);

The public interface is defined using extension methods on the IUnityContainer interface. There are two thing you have to do. Firstly, register all the MEF's catalogs in the Unity. Secondly, register the types in the Unity as you normally do. Note, however, that in order to make a type registered in the Unity container available to MEF, you must register it with an overloaded Register(Type|Instance) method that accepts a boolean as the last parameter. If it is true, registered type/instance will be available to MEF.
Sometimes you will want to suppress MEF injections into Unity created instances. Why? Because it costs you a CPU cycles (believe me, lots of them!). This is where PartNotComposableAttribute attribute comes in. Just mark a class with it, and when an instance from the Unity is returned, no MEF's imports will be satisfied, conserving CPU time. This is particularly useful for presenters.

Limitations

For now, MEF components can have Unity dependencies resolved only via constructor injection, so method injection on MEF components currently won't work.

Implementation details

The implementation is rather straightforward. It uses two Unity extensions and one custom MEF ExportProvider. As stated before, public interface is delivered as a set of extension methods on the IUnityContainer interface. I've also considered deriving directly from UnityContainer class, but the former approach (the one I've chosen) appears better suited for me. What do You think ? You can leave a comment on that :)

Conclusion

The idea of bringing the power of both frameworks is very tempting. And provided solution, although definitely not the only one, seems like a good one. The code + tests (NUnit 2.5) + demo app is available on my code gallery. Hope you like it!

Update
I've reimplemented most of the layer from the ground up, now it's a part of the MEFContrib project. Please see my post about it here.

Mammoth Pattern Miner 2009 April CTP Showcase

noreply@blogger.com (Piotr Włodek) — Tue, 05 May 2009 08:03:00 +0000

As promised in my last post about Mammoth some time ago, here's a four minute video presenting Mammoth in action. The video was made by co-author of Mammoth, my friend Arkadiusz Świerczek, and was presented on Europoltech 2009 conference in Warsaw. The video is soundless and is in polish, but if you're not polish, you can still get the idea of what Mammoth is all about :)

Just to let you know (if you already don't), Mammoth is a data mining and visualization solution that can discover frequent and user defined patterns in various sets of data. The program is easily extensible, so adding new algorithms, visualizations, etc., is a piece of cake.

We plan to release public, free version by the end of august 2009.

Since the last CTP, we have slightly updated technologies that are behind Mammoth. So besides .NET 3.5 SP1, WPF, Prism 2.0, Unity 1.2, Enterprise Library 4.1 and SQL Server 2005, we are using Managed Extensibility Framework Preview 5 which is labeled as a stable release.

As far as MEF is concerned, we've developed custom, simple yet robust Unity + MEF integration layer. As far as I can say for now, our MEF + Unity integration layer works flawlesly and provides combined power of both frameworks. If you are curious how we did it, check it out on my SVN Code Gallery. I will also write a separate post entirely devoted to MEF + Unity integration related stuff.

Meanwhile, enjoy the vid!

Parallel Coordinates in WPF - Part 1

noreply@blogger.com (Piotr Włodek) — Mon, 06 Apr 2009 12:15:00 +0000

A few days ago I have completed working on a first version of a parallel coordinates chart, that has been incorporated into Mammoth Pattern Miner 2009 (see my post about it). Before rolling out my own implementation, I went through the internet trying to find any implementation with the attached source code. As a result, I found a nice post here, but without the sources. Thus, I have developed a nice looking, styleable (via custom control templates) parallel coordinates chart myself :) And despite the fact that I did it under my "company" time, my boss and I decided that it would be great if I posted the sources as well. So I did! :) This is how the diagram looks like:

Overall look and feel of the demo application

This is a first post about PC chart. It covers all the functionality the chart contains, and info about using it from the code. Next posts in this series will cover the chart internals.

Feature List

1. Lines highlighting / selecting and tooltips

1. Axes labels and range labels, helper axis

2. Diagram manipulation
Anytime you resize the window or manipulate the axes, you can fit the diagram to the current view. Simply right click anywhere on the diagram and choose "Fit To Screen" command as shown below.

Besides, you can interact with the diagram using two tools: Select and Grab. If you pick the Select Tool (default), you can select/deselect lines, rotate/swap/move/scale axes. And if you pick the Grab Tool, you can move the diagram. Bear in mind that anytime you manipulate the diagram, you can execute the "Fit To Screen" command to return to the optimal view.

3. Axis scaling / Points Moving

When your mouse is over any axis, you can move the points on it simply by clicking LMB and moving the mouse up and down or you can scale it using the mouse wheel. When the mouse cursor isn't over any axis, using the mouse wheel will scale all the axes. You can scale/move the helper axis as well :)

4. Axis rotating
Axis rotating simply reverses the axis direction. To rotate the axis, move the mouse cursor over it and click the button that will appear at the bottom of the highlighted axis.

5. Axis swapping
You can swap two axes by dragging the source axis (with left CTRL button pressed) and dropping it on the destination axis. After this, the source and the destination axes will swap their placements (see the picture below).

Using the PC chart

Using the chart is very straightforward. First, you need to add the Chart control. This is done in XAML like so:


<Charts:Chart DataSource="{Binding DataSource}" />

Now, you have to prepare the data. Suppose you want to visualize a collection of the following class.


public class DemoInfo
{
public double X { get; set; }
public double Y { get; set; }
public double Z { get; set; }
public double V { get; set; }
public double K { get; set; }
public double M { get; set; }
public int Tag { get; set; }
}

All you have to do is: grab the data, create an appropriate data source, add property to axis mapping, name the labels, and that's it!


public void DataBind()
{
 IList<DemoInfo> infos = new List<DemoInfo>();

 // Generate random data
 for (int i = 0; i < ObjectsCount; i++)
 {
     var x = new DemoInfo();
     x.X = m_Random.NextDouble() * 400 - 100;
     x.Y = m_Random.NextDouble() * 500 - 100;
     x.Z = m_Random.NextDouble() * 600 - 300;
     x.V = m_Random.NextDouble() * 800 - 100;
     x.K = 1.0;
     x.M = i;
     x.Tag = i + 1;

     infos.Add(x);
 }

 // Create the data source and apply mappings
 var dataSource = new MultiDimensionalDataSource<DemoInfo>(infos, 6);
 dataSource.MapDimension(0, info => info.X);
 dataSource.MapDimension(1, info => info.Y);
 dataSource.MapDimension(2, info => info.Z);
 dataSource.MapDimension(3, info => info.V);
 dataSource.MapDimension(4, info => info.K);
 dataSource.MapDimension(5, info => info.M);


 // Name the labels
 dataSource.Labels[0] = "X";
 dataSource.Labels[1] = "Y";
 dataSource.Labels[2] = "Z";
 dataSource.Labels[3] = "V";
 dataSource.Labels[4] = "K";
 dataSource.Labels[5] = "M";
 dataSource.HelperAxisLabel = "Helper axis";

 myChart.DataSource = dataSource;
}

Full source code is available here. Note that I use M-V-VM approach :)
Hope you like it!

Exam 70-536 passed :)

noreply@blogger.com (Piotr Włodek) — Sun, 15 Mar 2009 21:23:00 +0000

Three days ago (being more specific, on Friday 13th ;) ) I've passed my first Microsoft developer's exam, 70-536 TS: Microsoft .NET Framework - Application Development Foundation, scoring 876 points out of 1000. In short, I had 40 question and 135 minutes. As far as questions are concerned, there were many about serialization (rather not very straightforward), interoperability and globalization. No questions about mailing functionality. The questions ranged from very simple to quite though. Most of them were single choice questions, I got maybe three or four multiple choice ones.

Some say this is an easy exam. Well, I wouldn't say so, because the exam covers almost every .NET basic subject. In order to pass, you need to have solid theoretical background, but at the same time you need to get you hands dirty by playing with some code samples too. I recommend examining the official Training Kit (now there's 2nd edition, the first one was quite buggy so don't rely only on that book). Skimming MSDN seems like a good idea too ;) However, there's no better source of knowledge than the developer's head and experience. Most of the questions I answered because of my experience and not because of the books!

Next, I'm going for the exam 70-502: Microsoft® .NET Framework 3.5—Windows® Presentation Foundation. Good luck with your own certifications!

Lack of AttachNewRegion method in Prism 2.0

noreply@blogger.com (Piotr Włodek) — Tue, 24 Feb 2009 21:38:00 +0000

Today I have switched to Composite WPF and Silverlight 2.0 (known as Prism 2.0) in one of my current projects. The transition was quite smooth (I used a guide which I found here), although I found one issue - the IRegionManager interface does not contain the AttachNewRegion method :( This made me very unhappy because I used this method in the implementation of a IMenuService which is responsible for managing the main menu control within my application by exposing a friendly interface to all modules. After small source code investigation I realized that indeed there's no sign of the mentioned method. After reading interesting post here, I decided to write one myself, which was a trivial task ;) Here's the code:



using System;
using System.Windows;
using Microsoft.Practices.Composite.Presentation.Regions;
using Microsoft.Practices.Composite.Regions;

namespace Mammoth.Presentation.Infrastructure.Common
{
   public static class RegionManagerExtensions
   {
       public static void AttachNewRegion(this IRegionManager regionManager, object regionTarget, string regionName)
       {
           if (regionManager.Regions.ContainsRegionWithName(regionName))
               throw new ArgumentException("Region already exists.", regionName);

           RegionManager.SetRegionManager((DependencyObject) regionTarget, regionManager);
           RegionManager.SetRegionName((DependencyObject) regionTarget, regionName);
       }
   }
}

As you can see, this is a very simple extension method that extends the IRegionManger interface. Inside, I simply set the region manager and the region name on the desired UI element.

This solution is very simple, still it works fine (at least for me). If you have any troubles with it, let me know.