Bnaya Eshet : Silverlight

Testing and Debugging MEF, avoiding misconceptions - Part 3

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

Testing and Debugging MEF, avoiding misconceptions - Part 3

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

discuss common misconceptions which may lead unexpected behavior and long

debugging nights.

Initialization issues

the first misconception occurs when developer are trying to access

imported property at construction time.

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

MyPlugin instantiation occur when the MEF container composed,

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

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

the above code will result with NullReferenceException.

What can we do about it?

we can have a few solutions solving this issue:

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

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

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

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

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

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

None composed instance issue

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

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

How can we do it right?

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

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

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

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

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

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

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

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

which hold CompositionHost.Initialize and CompositionInitializer.SatisfyImports

from here.

Exporting the wrong type issue

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

MEF does not goes through the inheritance list,

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

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

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

it is equivalent to:

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

while what you may really wanted is:

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

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

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

Summary

MEF instantiation occurs at runtime and sometime it is not

so easy or straight forward for debug.

avoiding common misconceptions may save us long debugging hours.

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

MEF for Beginner (Deployment Catalog) - part 12

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

MEF for Beginner (Deployment Catalog) - part 12

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

this post will focus on Deployment Catalog.

the code sample for this post can be found here.

What is MEF Deployment Catalogs?

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

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

Code sample

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

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

at the startup (app.xaml)

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

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

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

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

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

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

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

line 18, start downloading the xap.

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

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

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

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

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

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

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

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

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

Summary

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

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

the code sample for this post can be found here.

Learn more

Rx - for beginners (part 11): ObserveOn

bnaya — Mon, 29 Mar 2010 15:19:49 GMT

Rx - for beginners (part 11): ObserveOn

this post is the 11th in a series of posts about the new Reactive Framework (Rx).

the series TOC can found here.

in this post we will focus on the ObserveOn…

the code sample for this post can be found here.

sometime it is important that the observation will occurs on specific thread.

for example GUI application like (WinForm, WPF and Silverlight) throw exception whenever

UI component accessed on thread different than its creation thread.

ObserveOn instruct the producer (observable) to call the consumer (observer) on specific thread.

having the following Xaml:

Code Snippet
 <Window x:Class="ObserveOnSample.Window1"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    Title="Window1" Height="300" Width="300">
    <Grid>
        <TextBlock x:Name="_txt" Text="Not set"/>
    </Grid>
</Window>
 

if we want to change the Text property of the text box, we mast do it on the Dispatcher thread.

doing it we have to add the ObserveOnDispather, as shown in the next snippet (line 8):

Code Snippet
 public partial class Window1:Window
{
    public Window1()
    {
        InitializeComponent();
 
        var timeStream = Observable.Interval(TimeSpan.FromSeconds(1));
        var timeStreamDispather = timeStream.ObserveOnDispatcher();
        timeStreamDispather.Subscribe(value => _txt.Text = value.ToString());
    }
}
 

the sample create interval producer (observable) on line 7.

then it ensure that observation will occurs at the dispatcher thread (line 8).

and subscribe to the synchronized producer (observable) on line 9.

Summary

you can use Rx to synchronize your operation to the right thread.

the code sample for this post can be found here.

recommending VS 2010 XAML IntelliSense Extension

bnaya — Fri, 26 Mar 2010 18:12:38 GMT

recommending VS 2010 XAML IntelliSense Extension

a pal named Karl had published a very useful plug-in to VS 2010.

this plug-in is making Xaml writing so much better experience with enhanced IntelliSense.

if you doing some Xaml work using VS 2010 you should consider to download this plug-in.

the download is available from the following link:

http://karlshifflett.wordpress.com/2010/03/21/visual-studio-2010-xaml-editor-intellisense-presenter-extension/#comment-2228

Features

Pascal case lookup
Optional narrowing list filter
Filtering based on item type
xmlns IntelliSense options
- Show/hide only solution assemblies
- Show/hide schemas
Filter settings persist for the current Visual Studio session

MEF Preview 9 released

bnaya — Fri, 26 Feb 2010 14:51:14 GMT

MEF Preview 9 was released

MEF preview 9 changes will be reflected the in the release of .NET 4.0 and Silverlight 4.0.

except from bug fixing, there was some changes to the API,

most of the changes is related to System.ComponentModel.Composition.Initilization.dll,

which is not yet available only for none Silverlight application :-(

here is a short list of API changes:

PackageCatalog were brought back, and changed it name to DeploymentCatalog.
PartCreator was renamed to ExportFactory.
PartInitializer was renamed to CompositionInitializer
CompositionHost.InitializeContainer was renamed to CompositionHost.Initialize

i do hope that the System.ComponentModel.Composition.Initilization.dll will finally find it place

into the CLR 4.0 release.

you can download it from the MEF codeplex.

the information was taken from Wes' Puzzling Blog.

UPDATES:

From: Glenn block

Unfortunately we will not be shipping CompositionInitializer / Host as part of .NET 4.0. .NET 4.0 and SL are on different ship cycles and the desktop locked long before we had the functionality in SL. We will do an OOB release on codeplex for desktop. I currently have an early version on my SkyDrive, but we will get bits updated for codeplex. The plan is to role CI into the desktop in the future.

תגים של Technorati:‏ MEF,Composition,Import,InportMany,Export,Extension

MEF for Beginner (Catalogs) - part 10

bnaya — Sat, 13 Feb 2010 21:10:42 GMT

MEF for Beginner (Catalogs) - part 10

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

this post will focus on Catalogs.

What is MEF Catalogs?

MEF container is using catalogs as its search area definition.

the catalog have instructions about where can MEF look for

the compose-able parts (import and export definitions).

in short catalogs are actually a discovery instruction.

Out of the box catalogs

MEF is shipping with the following out of the box catalogs:

Code Snippet
 var typeCat = new TypeCatalog(typeof(IFoo));
var asmCat = new AssemblyCatalog(typeof(Program).Assembly);
var dirCat = new DirectoryCatalog("US", "*.dll");
var aggCat = new AggregateCatalog(typeCat, asmCat, dirCat);
var container = new CompositionContainer(aggCat);
container.Compose(...);
 

TypeCatalog (line 1) define that specific types should includes in the discovery process.
DirectoryCatalog (line 2) instruct the discovery process to search for compose-able pars
within specific assembly.
DirectoryCatalog (line 3) is the most common used catalog, which instruct MEF to
search for compose-able parts within assemblies under specific directory using search pattern ("*.dll").
AggregateCatalog (line 4) is aggregation of different catalogs instances.
this catalog enable to add and remove catalogs at runtime.

UPDATE

Silverlight (CTP 9) introduce new catalog named DeploymentCatalog which should replace the PackageCatalog.

my next post will discuss more on this topic (soon).

Silverlight is adding the PackageCatalog which is searching within assemblies which include

~~in the package.~~

~~the following snippet demonstrate the Silverlight PackageCatalog:~~

Code Snippet
 var catalogs = new PackageCatalog();
catalogs.AddPackage(Package.Current);
var container = new CompositionContainer(catalogs);
container.Compose(...);
 

~~as you can see the PackageCatalog can include multiple packages.~~

Summary

The catalogs use to define the search boundary of the composition container discovery process.

different catalogs can be use for different boundary ranges.

Samples

each of the previous parts of this series contains samples which is using catalogs

you can explore the previous parts from the TOC.

תגים של Technorati:‏ MEF,export,import,importmany,extention,ioc,catalogs,composition

MEF for Beginner (repeatable metadata) - part 9

bnaya — Fri, 29 Jan 2010 20:02:27 GMT

MEF for Beginner (repeatable metadata) - part 9

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

this post will focus on having repeatable metadata definition (cases like definition of multiple categories).

if you not familiar with the MEF metadata concept you may want to read part 8.

Bad practice for repeatable metadata

In order to explain repeatable metadata, we will start by decorating export with

untyped metadata declaration (which consider as bad practice, use typed metadata

whenever you can, it is mach usable and reducing runtime failure).

Code Snippet
 [Export(typeof(IPlug))]
// using untyped metadata considered as bad practice
[ExportMetadata("Categories", Category.Travel, IsMultiple = true)]  
[ExportMetadata("Categories", Category.City, IsMultiple = true)]   
public class NewYork : IPlug
{
    public void Write() { Console.WriteLine("New York"); }
}
 

the above code snippet decorate the plug-in with categories metadata for both Travel and City (line 3,4).

notice that we should explicitly declare that those decoration is multiple (IsMultiple=true).

line 1: define the export.

latter on this post we will see the best practice of declaring the metadata using custom attribute.

Metadata view contract for repeatable metadata definition

the metadata view contract properties type, for repeatable metadata decoration, should be Array, or IEnumerable.

the following metadata view contract is capable to handle the above metadata decoration:

Code Snippet
 public interface IMetadataView
{
    Category[] Categories { get; }
}
 

as you can see, line 3, define property that match the name of our metadata decoration (Categories)

and it is using array for its data type.

Best practice for metadata definition

as in the previous part, the best practice for metadata definition is

using typed metadata, which mean to define attribute for the metadata.

Code Snippet
 [MetadataAttribute]
[AttributeUsage(AttributeTargets.Class, AllowMultiple = true)]
public class CategoryAttribute : Attribute
{
    public CategoryAttribute(Category category)
    {
        Categories = category;
    }
    public Category Categories { get; private set; }
}
 

as you can see it is almost identical for the definition of non-repeatable metadata attribute,

but with 2 differences:

we should declare that the attribute allow multiple occurrence (at the end of line 2),
this definition is equivalent to the IsMultiple definition on the untyped metadata.
we should derive from Attribute (instead of ExportAttribute, otherwise we will get multiple
instantiation of our plug-in).

the plug-in decoration will look as follow:

Code Snippet
 [Export(typeof(IPlug))]
[Category(Category.Game)]
[Category(Category.News)]
public class Football : IPlug
{
    public void Write() { Console.WriteLine("Football"); }
}
 

in term of code safety typed metadata leaving less margin for errors,

and it is match more usable because it is easier to understand which value are expected.

The Import decoration

our import should use the Lazy<IPlug, IMetadataView> in order to get the metadata information

(through the IMetadataView contract ).

Code Snippet
 [ImportMany]
public Lazy<IPlug, IMetadataView>[] Plugins { get; private set; }
 

Interrogating the metadata

the following code will compose and interrogate the metadata.

Code Snippet
 class Program
{
    static void Main(string[] args)
    {
        var instance = new Program();
        var cat = new AssemblyCatalog(typeof(Program).Assembly);
        var container = new CompositionContainer(cat);
        container.ComposeParts(instance);
 
        foreach (var plug in instance.Plugins)
        {
            plug.Value.Write();
            foreach (var category in plug.Metadata.Categories)
            {
                Console.Write(", {0}", category);
            }
        }
    }
 
    [ImportMany]
    public Lazy<IPlug, IMetadataView>[] Plugins { get; private set; }
}
 

lines 6-8, is handling the composition.

line 10, iterating for each of the discovered plug-in.

line 13, iterating for each of the items in the metadata categories property upon specific plug-in.

Summary

having multiple metadata on the same export is slightly more challenging.

the main difference between working with repeatable metadata relate to the metadata decoration (AllowMultiple=true)

and having Array or IEnumerable at the metadata view properties level.

Download the code

the full code snippet for the samples covered by this post available in here,

full project download for the post sample and for WPF sample that using this post concept for

dynamic filtering of widgets by categories (as shown bellow), is available here for 2008, and here for 2010.

filtering widgets by categories sample (2010, 2008).

Point of interest

do not use setter on your metadata view interface.
do not use the [InheritedExport] because for some some strange reason it doesn't functioning well along with metadata.
if you want to build advance metadata view contract you can use class instead of interface,
but that class must have constructor with the following signature:
public ClassName (IDictionary<string, object> metadata)
inside the constructor you should map the metadata dictionary to the class properties.

תגים של Technorati:‏ MEF,Extensibility,Importmany,Export,Import,IoC,SELA,composition

MEF for Beginner: TOC

bnaya — Sat, 09 Jan 2010 16:26:22 GMT

MEF for beginner is a blog series for developers that want to learn

How To use the MEF (Manage Extensibility Framework) technology.

the following post is currently available for this series:

Concept

How To build your first MEF application

Hello Silverlight

A-sync Silverlight loading

Import

Part Creation policy

Recomposition policy

Metadata (part 1)

Metadata (part 2 – repeatable)

Catalogs

Import from Xaml

Deployment Catalog

תגים של Technorati:‏ MEF,Beginner,Composition,Extensibility,IoC,SELA,Silverlight,WPF,Plug-in

Code cartoons - MEF

bnaya — Wed, 30 Dec 2009 02:24:47 GMT

Code cartoons – MEF

The super hero agency

MEF for Beginner – Part 4 (a-sync Silverlight loading)

bnaya — Sun, 27 Dec 2009 03:13:28 GMT

MEF for Beginner – Part 4 (a-sync Silverlight loading)

in this post we will continue from the point that we left our Silverlight application at part 3 of this series.

the post will focus on how to consume external plug-ins using a-sync loading into Silverlight application using MEF.

you can find more about the MEF on part 1, part 2 and part 3 of this series.

this post is written on Visual Studio 2010 and Silverlight 4.0 (using Visual studio 2008 and Silverlight 3

will need some minor modification and download the MEF Silverlight 3 bits from the MEF site).

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

if you want to start from our previous post code, you can download it from here.

Step 1: Download the Silverlight 4 Beta Toolkit

downloading a-sync Silverlight Packages (XAP) does not include in in the box at this point (i hope it will on the release time),

so you have to download the Silverlight 4 Beta Toolkit, which you can download here. You’ll need latter on this post.

Step 2: Create XAP (Silverlight App) for the new plug-in

the a-sync discovery technique that we are going to use in this post, will search for plug-ins in XAP files

that was deployed at the same virtual folder as our shell application deployed.

therefore we have to create Silverlight application rather then Silverlight class library.

create Silverlight application.

before approving the new application you have to uncheck the "make it the start page" check box

so it will keep the current Silverlight application as the startup application.

Step 2.1: delete the App.xaml

delete the app.xaml from the plug-in application, we don't need it there.

Step 3: add reference to MEF

before adding the plug-able functionality, we have to add reference to MEF.

add new reference and browse for System.ComponentModel.Composition.dll under the following folder:

64 bit: C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client

32 bit: C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries\Client

Step 4: Change the main page xaml (plug-in application)

at the plug-in application that we created in the previous step, change the MainPage.xaml to:

Code Snippet
 <Grid x:Name="LayoutRoot" Background="White">
    <Button Command="{Binding}" Width="Auto" Height="Auto">
        <TextBlock Text="External plug"/>
    </Button>
</Grid>
 

we are using the main page as our plug-in.

Step 5: Expose the plug-in

go the the code behind of the plug-in MainPage.xaml and decorate the class with the following Export attribute:

Code Snippet
 [Export(typeof(UserControl))]
public partial class MainPage : UserControl, ICommand
{
    public MainPage()
    {
        InitializeComponent();
 
        DataContext = this;
    }
 

add using to System.ComponentModel.Composition

and set the DataContext to this.

Step 5.1: Add Imports

adding imports for the exposed shell TextBlock and Border.

Code Snippet
 [Import]
public TextBlock ShellText { get; set; }
 
[Import]
public Border ShellBorder { get; set; }
 

Step 6: implement the ICommand interface

add the ICommand to the inheritance of the class and implement the interface.

the Execute method should look like the following code:

Code Snippet
 public void Execute(object parameter)
{
    ShellText.Text = "External plug";
    ShellText.FontSize = 32.0;
    ShellBorder.Background = new SolidColorBrush(Colors.Yellow);
    var grdCol = new GradientStopCollection();
    grdCol.Add (new GradientStop { Color=Colors.Green, Offset=0});
    grdCol.Add (new GradientStop { Color=Colors.Purple, Offset=0.25});
    grdCol.Add (new GradientStop { Color=Colors.Orange, Offset=0.5});
    grdCol.Add (new GradientStop { Color=Colors.Blue, Offset=0.75});
    var brush = new LinearGradientBrush (grdCol,45);
    ShellText.Foreground = brush;
}
 

Step 7: A-Sync composition

add reference to the System.ComponentModel.Composition.Packaging.Toolkit.dll to the shell project

you should find it at:

C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Toolkit\Nov09\Bin\System.ComponentModel.Composition.Packaging.Toolkit.dll for 64 bit

C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Toolkit\Nov09\Bin\System.ComponentModel.Composition.Packaging.Toolkit.dll for 32 bit

Step 7.1: Allow Recomposition

the a-sync composition will result in re-adding plug-ins to the existing plug-ins collection,

this behavior required to modify the Import policy to allow recomposition.

at the shell project, MainPage.xaml code behind, modify the import declaration to:

Code Snippet
 [ImportMany (AllowRecomposition=true)]
public ObservableCollection<UserControl> ToolbarItems { get; set; }
 

Step 7.2: Minor changes to the InitializeContainer method

because we will need the PackageCatalog latter for adding the new

discovered packages we have to take it out to the class level scope.

at the app.xaml code behind , change the InitializeContainer method as follow:

Code Snippet
 PackageCatalog _catalogs = new PackageCatalog();
private void InitializeContainer(UIElement mainWin)
{
    _catalogs = new PackageCatalog();
    _catalogs.AddPackage(Package.Current);
    var mainWinPart = AttributedModelServices.CreatePart(mainWin);
    var batch = new CompositionBatch(new[] { mainWinPart }, null);
    var container = new CompositionContainer(_catalogs);
    container.Compose(batch);
}
 

Step 7.3: Loading external plug-ins

Code Snippet
 private void Application_Startup(object sender, StartupEventArgs e)
{
    this.RootVisual = new MainPage();
    InitializeContainer(this.RootVisual);
    var uri = new Uri("MyPlugIn.xap", UriKind.Relative);
    Package.DownloadPackageAsync(uri,
        (args, p) =>
        {
            Thread.Sleep(3000);// just waiting in order to emphasize the a-sync effect
            _catalogs.AddPackage(p);
        });
}
 

lines 5-11 are responsible for the a-sync package loading.

Summary

the a-sync pattern is really powerful, and we can benefit from better startup time of the

Silverlight application by pushing heavy loading into plug-able components (which will be loaded a-sync).

another benefit is the capability of on demand plug-ins loading.

Downloads

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

you will need Silverlight 4 and the Silverlight 4 toolkit. You can download Silverlight 4 beta here and the toolkit here.

Learn More

you can find more information on how to use MEF over Silverlight in the following posts (by Glenn Block):

Building Hello MEF – Part III – XAP Partitioning (with the host’s permission) and the sweetness of recomposition.

Point of Interest

if you living in Israel you can hear me speaking about MEF at the SDP at Monday 28.12.2009 (mark your calendar)

MEF for Beginner – Part 3 (Hello Silverlight)

bnaya — Sun, 20 Dec 2009 02:21:42 GMT

MEF for Beginner – Part 3 (Hello Silverlight)

in this post we will cover the basic steps that is needed for building your first Silverlight MEF application.

you can find more about the MEF on part 1, part 2 of this series, the series TOC is available here.

the following instructions will lead you through very simple steps of building simple Silverlight shell application

that can consume plug-ins.

this post is written on Visual Studio 2010 and Silverlight 4.0 (using Visual studio 2008 and Silverlight 3

will need some minor modification and download the MEF Silverlight 3 bits from the MEF site).

in the next post on this series, we will extend the current post by learning how to consume external plug-ins using a-sync loading .

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

Step 1: Creating Silverlight Application

Create solution using the Silverlight application template.

Step 2: Setting the Shell layout

the layout of the shell will have 2 area (plug-in command area and main area):

the plug-ins commands will host in StackPanel control

and the main content area will have a Border and TextBlock controls within a Canvas.

add the following Xaml into the Grid element of the main page.

Code Snippet
 <Grid.ColumnDefinitions>
    <ColumnDefinition Width="150" />
    <ColumnDefinition Width="308*" />
</Grid.ColumnDefinitions>
<StackPanel Orientation="Vertical" Grid.Column="0">
</StackPanel>
<Canvas x:Name="_mainContentPlaceHolder" Grid.Column="1" >
    <Border x:Name="_mainBorder" Width="250" Height="100" BorderThickness="1" CornerRadius="1" Margin="4">
        <TextBlock x:Name="_mainText" Text="Some content"/>
    </Border>
</Canvas>
 

Step 3: Binding the StackPanel to plug-ins list

add the ItemControl element into the StackPanel (see it's binding definition)

Code Snippet
 <StackPanel Orientation="Vertical" Grid.Column="0">
    <ItemsControl ItemsSource="{Binding Path=ToolbarItems}" />
</StackPanel>
 

add ObservableCollection of UserControl property called ToolbarItems into the Shell code behind
(the binding definition at the Xaml level refer to this property)

Code Snippet
 public ObservableCollection<UserControl> ToolbarItems { get; set; }
 

initialize the ToolbarItems property and the Context at the constructor,

(the following lines should be add to the constructor).

Code Snippet
 ToolbarItems = new ObservableCollection<UserControl>();
DataContext = this;
 

Step 4: add reference to MEF

before adding the plug-able functionality, we have to add reference to MEF.

add new reference and browse for System.ComponentModel.Composition.dll under the following folder:

64 bit: C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client

32 bit: C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Libraries\Client

Step 5: decorate the ToolbarItems property

decorating the ToolbarItems property with ImportMany attribute, will shift the responsibility of

filling it with UserControl instances to MEF (which is basically saying to MEF

that it should add any item that was Export and match the contract (in our case UserControl).

the ToolbarItems should now look like this:

Code Snippet
 [ImportMany]
public ObservableCollection<UserControl> ToolbarItems { get; set; }
 

Step 6: expose the Element within the main area

the shell will expose the Border and the TextBlock within it main area so it can be

discoverable by the plug-ins.

to achieve this task we will add 2 properties (at the code behind) and decorate it with Export attribute.

Code Snippet
 [Export]
public TextBlock MainText
{
    get { return _mainText; }
}
 
[Export]
public Border MainBorder
{
    get { return _mainBorder; }
}
 

Step 7: Create exportable entities (create plug-ins)

Note: on this post we will add the plug-ins within the same package as our Shell,

but in the next post in this series we will show how to discover exportable

parts within external packages.

Create Parts folder in the project and add Silverlight User Control (PlugableEffect1.xaml)

Step 7.1: Stet the look and feel of the effect command

add the following Xaml into the Grid element (of the effect xaml)

Code Snippet
 <Button Command="{Binding}" Width="Auto" Height="Auto">
    <TextBlock Text="Effect 1"/>
</Button>
 

Step 7.2: Add TextBlock property that present the TextBlock at the Shell main area

also this plug-in is capable of manipulate a TextBlock, it shouldn't be aware of

the TextBlock origin.

to achieve the above requirements we will once again add decorated property,

which will be assigned by MEF at runtime.

this time we expecting single value, therefore we will decorate the property with the Import attribute

rather the ImportMany attribute.

Note: MEF will find the exported TextBlock which we expose at step 6 and assign it into the following property.

Code Snippet
 [Import]
public TextBlock ShellText { get; set; }
 

Step 7.3: Set the effect command

looking at the Xaml of the button we can see that it use the Command="Binding"

this mean that the button expect ICommand implementation within it's data context.

at the code behind of this effect, add the following line to the constructor.

Code Snippet
 DataContext = this;
 

and implement ICommand

Code Snippet
 public partial class PlagableEffect1 : UserControl, ICommand
 

Code Snippet
 public bool CanExecute(object parameter)
{
    return true;
}
 
public event EventHandler CanExecuteChanged;
 
public void Execute(object parameter)
{
    ShellText.Text = "Effect 1";
    ShellText.FontSize = 32.0;
    ShellText.Foreground = new SolidColorBrush(Colors.Red);
    ShellText.FontFamily = new FontFamily("Comic Sans MS");
}
 

Step 7.4: Export our effect

making the effect visible to MEF done by decorating the class with Export attribute.

Code Snippet
 [Export(typeof(UserControl))]
public partial class PlugableEffect1 : UserControl, ICommand
 

Step 8: Create another exportable entities (create plug-ins)

repeat step 7 for Effect 2 (replace the Effect 1 text to Effect 2).

then add another property decorated with Import for the shell Border element.

Code Snippet
 [Import]
public Border ShellBorder { get; set; }
 

replace the Execute method implementation of the Effect 2 command to the following:

Code Snippet
 public void Execute(object parameter)
{
    ShellText.Text = "Effect 2";
    ShellText.FontSize = 24.0;
    ShellText.Foreground = new SolidColorBrush(Color.FromArgb(255, 33, 33, 33));
    ShellText.FontFamily = new FontFamily("Comic Sans MS");
    ShellText.FontWeight = FontWeights.ExtraBold;
    ShellText.VerticalAlignment = System.Windows.VerticalAlignment.Center;
    ShellText.HorizontalAlignment = HorizontalAlignment.Center;
 
    ShellBorder.BorderThickness = new Thickness(8);
    ShellBorder.BorderBrush = new SolidColorBrush(Colors.Gray);
    ShellBorder.CornerRadius = new CornerRadius(10.0);
    ShellBorder.Background = new SolidColorBrush(Colors.Orange);
    ShellBorder.Width = 250;
    var rt = new RotateTransform();
    rt.Angle = 45;
    rt.CenterX = 1.5;
    rt.CenterY = 30;
    ShellBorder.RenderTransform = rt;
}
 

Step 9: Compose it all together

before we continue we have to add reference to System.ComponentModel.Composition.Packaging.Toolkit.dll

this dll is part of the MEF Silverlight Toolkit

after installing the toolkit you can find the System.ComponentModel.Composition.Packaging.Toolkit.dll

at C:\Program Files (x86)\Microsoft SDKs\Silverlight\v4.0\Toolkit\Nov09\Bin (for 64 bit)

and at C:\Program Files\Microsoft SDKs\Silverlight\v4.0\Toolkit\Nov09\Bin (for 32 bit)

Step 9.1: Compose

the last step involve is asking MEF to compose.

we will supply MEF with some basics instruction and ask it to assign all the Import with

Export that matches the Import's needs.

Add the following method to the App.xaml code behind.

Code Snippet
 private void InitializeContainer(UIElement mainWin)
{
    var catalogs = new PackageCatalog();
    catalogs.AddPackage(Package.Current);
    var mainWinPart = AttributedModelServices.CreatePart(mainWin);
    var batch = new CompositionBatch(new[] { mainWinPart }, null);
    var container = new CompositionContainer(catalogs);
    container.Compose(batch);
}
 

the above code create a Catalog (at lines 3,4) ,

Catalog used as instruction for where to search for the compose-able parts.

in this case we instruct MEF to look for compose-able parts within the current Silverlight package.

at lines 5,6 we add the current instance of the Shell into CompositionBatch, this will instruct the MEF container

to use this instance rather of creating new one.

line 7, 8 add the Catalog and the CompositionBatch to a CompositionContainer and perform the composition.

the last peace of code is calling the above method from the application startup.

Code Snippet
 private void Application_Startup(object sender, StartupEventArgs e)
{
    this.RootVisual = new MainPage();
    InitializeContainer(this.RootVisual);
}
 

Summary

this post had demonstrate how to build compose-able shell using Silverlight 4.0.

in the next post we will continue to enhance the sample by adding a-sync loading capability

to external Silverlight packages that holding compose-able parts (Plug-ins).

Downloads

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

you will need Silverlight 4 and the Silverlight 4 toolkit. You can download Silverlight 4 beta here and the toolkit here.

Learn More

you can find more information on how to use MEF over Silverlight in the following posts (by Glenn Block):

Building the Hello MEF dashboard in Silverlight 4 - Part I

Building Hello MEF – Part II – Metadata and why being Lazy is a good thing.

Building Hello MEF – Part III – XAP Partitioning (with the host’s permission) and the sweetness of recomposition.

Updates

the MEF API for Silverlight Catalog has changed,

instead using the PackageCatalog you should now use the DeploymentCatalog.

other changes were:

PartIntializer renamed to CompositionInitializer (Silverlight only)

and PartCreator renamed to ExportFactory<T> and moved to System.ComponentModel.Composition.Initialization assembly (Silverlight only)

Who own that XAML?

bnaya — Sat, 05 Sep 2009 22:27:20 GMT

This post is about WPF / Silverlight separation of concern and on the continues question Who own that XAML?

Before we begin here is my proper disclosure:
I'm not an expert in WPF nor in Silverlight though take this post as a thought sharing and i would like to get your comments on that subject.

Background

The all subject emerge while i was listening to Herding Code podcast about MVVM.

So i was asking myself, how would i assemble UI team and have them working with great productivity and without ruin each other work?

The problem

The main failure point that everybody going around is that XAML thing, but some time it seem that the questions people asking isn’t the right one.

I’m thinking that the main question should be
who own the XAML? rather then
who’s touching the it and when?

I will go farther and argue that we should separate the XAML into 2 separate XAMLs.

1. Developer XAML

2. Designer XAML

each of the XAML has very clear ownership and very clear goal.

The developer XAML should be limit to hold sheer functionality without any beauty factor (target for the minimal view developer need in order to get it functioning).
Events wiring actions (not animation) will fall under the developer responsibility, MVVM command is even better.

The Designer XAML should target the followings:
- Styling
- Animation
- Enriched data templates

Binding the beauty factor

Farther thinking of switching between the developer view and the designer view, i come to the following idea.
I believe that the code behind should have properties which the data templates and styling should be bind to.
This properties can be initialize form configuration and this way (for testing purpose) we can switch to the developer view to see whether our problem cause by the design or functionality fault.

Summary

I believe that following that pattern we will end up with mach clearer separation of concern and higher productivity and maintainability.

I know that there is lot more aspects that i didn’t touch in this post (like unit testing and other) and i encourage you to leave comment expressing your thought on this subject.

Bnaya Eshet : Silverlight

Testing and Debugging MEF, avoiding misconceptions - Part 3

Testing and Debugging MEF, avoiding misconceptions - Part 3

Initialization issues

What can we do about it?

None composed instance issue

How can we do it right?

Exporting the wrong type issue

Summary

Read more

MEF for Beginner (Deployment Catalog) - part 12

MEF for Beginner (Deployment Catalog) - part 12

What is MEF Deployment Catalogs?

Code sample

Summary

Learn more

Rx - for beginners (part 11): ObserveOn

Rx - for beginners (part 11): ObserveOn

Summary

recommending VS 2010 XAML IntelliSense Extension

recommending VS 2010 XAML IntelliSense Extension

Features

MEF Preview 9 released

MEF Preview 9 was released

UPDATES:

MEF for Beginner (Catalogs) - part 10

MEF for Beginner (Catalogs) - part 10

What is MEF Catalogs?

Out of the box catalogs

UPDATE

Summary

Samples

MEF for Beginner (repeatable metadata) - part 9

MEF for Beginner (repeatable metadata) - part 9

Bad practice for repeatable metadata

Metadata view contract for repeatable metadata definition

Best practice for metadata definition

The Import decoration

Interrogating the metadata

Summary

Download the code

Point of interest

MEF for Beginner: TOC

Code cartoons - MEF

Code cartoons – MEF

The super hero agency

MEF for Beginner – Part 4 (a-sync Silverlight loading)

MEF for Beginner – Part 4 (a-sync Silverlight loading)

Step 1: Download the Silverlight 4 Beta Toolkit

Step 2: Create XAP (Silverlight App) for the new plug-in

Step 2.1: delete the App.xaml

Step 3: add reference to MEF

Step 4: Change the main page xaml (plug-in application)

Step 5: Expose the plug-in

Step 5.1: Add Imports

Step 6: implement the ICommand interface

Step 7: A-Sync composition

Step 7.1: Allow Recomposition

Step 7.2: Minor changes to the InitializeContainer method

Step 7.3: Loading external plug-ins

Summary

Downloads

Learn More

Point of Interest

MEF for Beginner – Part 3 (Hello Silverlight)

MEF for Beginner – Part 3 (Hello Silverlight)

Step 1: Creating Silverlight Application

Step 2: Setting the Shell layout

Step 3: Binding the StackPanel to plug-ins list

Step 4: add reference to MEF

Step 5: decorate the ToolbarItems property

Step 6: expose the Element within the main area

Step 7: Create exportable entities (create plug-ins)

Step 7.1: Stet the look and feel of the effect command

Step 7.2: Add TextBlock property that present the TextBlock at the Shell main area

Step 7.3: Set the effect command

Step 7.4: Export our effect

Step 8: Create another exportable entities (create plug-ins)

Step 9: Compose it all together

Step 9.1: Compose