Bnaya Eshet : IoC

MEF for Beginner (Deployment Catalog) - part 12

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

MEF for Beginner (Deployment Catalog) - part 12

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

this post will focus on Deployment Catalog.

the code sample for this post can be found here.

What is MEF Deployment Catalogs?

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

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

Code sample

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

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

at the startup (app.xaml)

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

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

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

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

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

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

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

line 18, start downloading the xap.

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

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

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

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

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

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

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

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

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

Summary

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

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

the code sample for this post can be found here.

Learn more

MEF 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

Catalogs (code cartoon)

bnaya — Tue, 16 Feb 2010 03:39:52 GMT

Catalogs (code cartoon)

catalog are search boundary for the composition container.

you can read more about MEF on MEF for beginner series, the TOC is available here

תגים של Technorati:‏ Extensibility,MEF,Composition,catalogs

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

does MEF apply the SOA paradigm?

bnaya — Tue, 09 Feb 2010 14:02:21 GMT

does MEF apply the SOA paradigm?

in this post I'm going to argue that the Manage Extensibility Framework (MEF),

is actually applying to the 4 tenet of Service Orientation Architecture (SOA),

therefore MEF is actually, in-process implementation of the SOA paradigm.

Background

when we speaking about SOA we used to think about technologies like web services and WCF,

which is cross process technologies.

but does SOA define that services should always be consumed from the clouds?

local services like loggers, rule engine, cache and more are everyday practice for in-process services.

What make your architecture, service oriented?

different architect having different opinions of how to construct SOA architecture,

but most of them agree that SOA design should apply to the 4 tenets of SOA.

The 4 tenets of SOA

Service should have Explicit Boundaries.

Service should be Autonomous.

Service API should rely on Contract.

Service behavior and compatibility should rely on Policy.

How MEF apply to the 4 tenets?

MEF boundaries define explicitly by the Export definition.

separating exports into separate dlls will create autonomous unit which has no need

for any reference but the reference for the services contract.

Imports does not aware of the actual implementation, imports are solely relay on the contract

(composition will find export that mach the import contract).

MEF has different policies mechanism like metadata, creation policy,

instantiation policy, recomposition.

Summary

despite MEF being an in-process technology it does apply to the 4 tenet of SOA,

therefore it can consider as such.

תגים של Technorati:‏ MEF,extensibility,SOA,CLR 4

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 (Recomposition policy) - part 7

bnaya — Sat, 16 Jan 2010 04:05:07 GMT

MEF for Beginner (Recomposition policy) - part 7

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

the current post will focus on the recomposition policy.

What is the recomposition policy?

by default the composition should assign the Import only once

(trying to recompose on already composed import will result with exception).

using the recomposition policy we can define that our Import

is allowing reassignment whenever the container is having changes.

What is it good for?

the recomposition can be handy for dynamic data discovery that can

changed during the application lifecycle

(you can put file watcher upon your DirectoryCatalog folder and refresh the catalog

when the change event occurs, this way you can add new plug-in at runtime).

you can also use it to reduce the pressure on your application startup

(by starting with few most common catalog at startup and latter adding the rest).

How to define recompose-able Import / ImportMany?

the following snippet demonstrate the decoration that needed in

order to define recompose-able Import / ImportMany:

Code Snippet
 [ImportMany(AllowRecomposition = true)]
public string[] Strings { get; set; }
 
[Import(AllowRecomposition=true)]
public string Str { get; set; }
 

as you can see, all it take is to set the AllowRecomposition to true.

Code Sample

the following code sample can be download from here,

it is demonstrating recomposition scenario.

Exported types:

Code Snippet
 internal class ExpMtd1
{
    [Export]
    public string GetString1 { get { return "GetString 1"; } }
    [Export]
    public string GetString2 { get { return "GetString 2"; } }
}
internal class ExpMtd2
{
    [Export]
    public string GetString3 { get { return "GetString 3"; } }
    [Export]
    public string GetString4 { get { return "GetString 4"; } }
}
internal class ExpMtdRuntime
{
    public ExpMtdRuntime(string s) { GetString = s;  }
    [Export]
    public string GetString { get; private set; }
}
 

the above code having 3 classes,

each of the 2 first classes ExpMtd1 and ExpMtd2 is simply exporting 2 string.

class ExpMtdRuntime is exporting single string that initialized at the construction time.

looking at the constructor it has no [ImportingConstructor] decoration which mean that

it won't be construct by MEF (we will manually instantiate it at runtime and then we will

introduce the instance to MEF).

Import

Code Snippet
 [ImportMany(AllowRecomposition = true)]
public string[] Strings { get; set; }
 

the import is decorated with the AllowRecomposition attribute, which define

that MEF can assign this property upon multiple composition.

Continues composition

the following code will demonstrate multiple compositions,

you can think on scenario like startup plug-ins loading, then latter adding less frequency used plug-ins,

or on demand plug-ins, that maybe adding new plug-ins that was initialize from data source.

Code Snippet
 private static ImpCls s_imp = new ImpCls();
private static string[] s_beforeState;
 
static void Main(string[] args)
{
    var c = new TypeCatalog(typeof(ExpMtd1));
    var catalog = new AggregateCatalog(c);
    var container = new CompositionContainer(catalog);
    container.ComposeParts(s_imp);
    Write(s_imp.Strings); // writing the state before recomposition 
 
    container.ExportsChanging += (s, e) => {
            s_beforeState = s_imp.Strings; // snapshot of the value before the recomposition assignment
        };
    container.ExportsChanged += (s, e) =>  {// getting the changes gap
            var gap = s_imp.Strings.Except(s_beforeState); 
            s_beforeState = null;
            Write(gap);
        };
    // adding new catalog (will result in recomposition)
    catalog.Catalogs.Add(new TypeCatalog(typeof(ExpMtd2))); 
    for (int i = 0; i < 10; i++)
    {   // adding export instance (will result in recomposition)
        container.ComposeParts(new ExpMtdRuntime ("Runtime " + i.ToString())); 
    }
}
 
private static void Write(IEnumerable<string> strings)
{
    foreach (var item in strings) { Console.WriteLine(item); }
}
 

line 1: s_imp is the instance of the class that having the imports.

line 2: this is temporary variable that we use for storing the state of the collection before the recomposition so

we can get the gap of the changes after the recomposition complete.

lines 6-9: standard MEF catalog initialization, at this stage we only adding the import instance (line 9)

and the ExpMtd1 type (line 6), the catalog does not yet includes the ExpMtd2 and ExpMtdRuntime.

lines 12-18: listening to the changing and changed events, so we will able to write the gap of the

newly discovered parts to the console, whenever the container will recompose.

line 21: adding the ExpMtd2 (by adding new TypeCatalog), it will cause recomposition.

line 22-25: continuously adding ExpMtdRuntime instances, it will cause recomposition for each iteration.

Summary

The recomposition can be very useful in real-life scenarios and it is quite simple to implement.

תגים של Technorati:‏ Extensibility,MEF,SeLA,ioC,Composition,CLR 4,.net

Secured directory catalog

bnaya — Fri, 08 Jan 2010 00:10:45 GMT

Secured directory catalog

I was discussing the question of how to secure your MEF application on this post

where I was publishing replica of the MEF bits hopping that the Secured Directory Catalog will

find its way into the MEF core.

but as sad as it is :(, it won't make into the core.

you can read more about the MEF team consideration here.

anyway Glenn Block has suggest a solution for haw to build the secured catalog

without rewriting half of the MEF core, so as you might guessed,

I had created new directory catalog that let you control the assembly loading of your plug-ins.

the implementation of the Secured Directory Catalog can be found here.

it is given without any warranty, but with full source code.

actually it is real small implementation which you should find easy to review.

so enjoy the secured way of the plug-ins injection.

MEF for Beginner – Part 5 (Import)

bnaya — Sun, 03 Jan 2010 03:30:57 GMT

MEF for Beginner – Part 5 (Import)

this is the 5th post on MEF for beginner series, you can see the previous post here, here and here.

this post will focus on the Import aspect.

we will soon learn about the different signature that can be apply with the Import decoration,

but before starting with that, we should introduce the Lazy<T> class

which is a first citizen at the MEF world, and part of the CLR 4 types.

Lazy<T> definition

Lazy<T> is used in order of delaying the actual instantiation until it actually needed.

in fact using Lazy<T> the actual instantiation will occur the first time the Value property is accessed or ToString method is called.

you can use the Lazy<T> when ever you want to delay the actual instantiation of the

object that were discovered by the MEF composition.

The Import / ImportMany decorations

MEF is trying to discover parts that apply to Import definition constraint.

we can think at the Import definition as a where clause of the Linq query

(the from clause will be define by the Catalog / Export provider which will discuss latter on this series).

out of the box MEF offer an attribute model for the Import definition.

Decoration options

out of the box MEF is offering 2 type of Import decorations:

1. [Import] for single discoverable part.

2. [ImportMany] for discovering multiple parts.

Note: you should use [ImportMany] if there is a possibility that MEF will discover multiple Exported parts

even if you need only one of those parts (you can latter filter one using Linq query).

if you ask for single part and MEF discovering multiple it will throw an exception or return null

(depending on the MEF policy which will discuss in the next post on this series).

Import single instance

as I said in the previous paragraph, you should not use the [Import] attribute unless

you really expecting single discovery (like the case of discovering UI shell).

you apply the [Import] decoration to properties that having a getter and a setter (the setter can be private),

actually you can decorate a private property too (not in Silverlight).

Note: you can also decorate fields but it considered as bad practice.

and you can use the Lazy<T> if you want delay instantiation.

Import decoration may look like the following code:

Code Snippet
  
[Import]
public ISay Hellow { get; private set; }
 
[Import]
public Lazy<ISay> HellowLazy { get; private set; }
 

in the sample above the Import contract is concluded from the type of the property,

while in the next sample it is explicitly define.

note that the Lazy<T> is not part of the contract.

Code Snippet
  
[Import(typeof(ISay))]
public ISay Hellow { get; private set; }
 
[Import(typeof(ISay))]
public Lazy<ISay> HellowLazy { get; private set; }
 

using explicit contract is useful while we want MEF to search for contract of specific derived

type and not for the type of the property itself.

in case that the Imported property can have null value you should add the AllowDefault=true

to the Import decoration ( it will look like the following [Import (AllowDefault=true)] ).

Import multiple values

Importing multiple values is done by using the [ImportMany] attribute.

we can assign this attribute to properties that having IEnumerable<T>, Array ([]) and

any type that derived from ICollection<T>.

the types within the above sets can be Lazy<T> for having delay instantiation.

the following code snippet will demonstrate the use of [ImportMany] decoration:

Code Snippet
 [ImportMany]
public ISay[] AsArray { get; private set; }
 
[ImportMany]
public IEnumerable<ISay> AsEnumerable { get; private set; }
 
[ImportMany]
public List<ISay> AsCollection { get; private set; }
 
[ImportMany]
public Lazy<ISay>[] AsLazyArray { get; private set; }
 
[ImportMany]
public IEnumerable<Lazy<ISay>> AsLazyEnumerable { get; private set; }
 
[ImportMany]
public List<Lazy<ISay>> AsLazyCollection { get; private set; }
 

Construction time import

the last capability I'm going to discuss in this post,

is one that I advice against using whenever you can, because it can lead to

cross composition reference. just for knowing what to avoid from

I will now introduce you to the [ImportingConstructor].

the [ImportingConstructor] can be decorate constructor that should be use by

the MEF composition, so any parameter of this constructor is

treated as import which should be satisfied.

the constructor may look as follow:

Code Snippet
 [ImportingConstructor]
public Rumors(ISay hello)
{
}
 

Summary

in this post we learn which signature can be apply to the import definitions

and we present the Lazy<T> type and its role under the MEF world.

on the next post at this series we will survey different MEF policies that

can affects the behavior of the MEF composition process.

code snippet (console application) can be download from here.

תגים של Technorati:‏ meF,extensibility,Import,importmany,ioc,composition

Code cartoons - MEF

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

Code cartoons – MEF

The super hero agency

Why and When slides from my MEF lecture

bnaya — Wed, 30 Dec 2009 01:39:12 GMT

Why and When slides from my MEF lecture

some time we are so enthusiastic about the technology,

that we forgot to explain the Why and When.

so I thought it could be nice to share those aspects with you.

when we asking Why to use the MEF technology we can think on the following reasons:

• Simple to understand

• Simple to implement

• The CLR 4 Extensibility standard

• Contract based model (type safe)

• Easy deployment (support copy / paste deployment)

• Zero configuration

• Ease of Maintenance

• Silverlight support

rules of thumb for When should we consider using MEF.

when ever we are using or considering one of the following,

we may use MEF instead:

• Reflection

• Factory pattern

• Command pattern

• Any other creational pattern

• IoC (Inversion of control)

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)

Pocket MEF is now supporting Windows CE

bnaya — Sat, 26 Dec 2009 14:51:38 GMT

Pocket MEF is now supporting Windows CE

One of our customer (at SELA Group) was asking for MEF solution that targeting the Windows CE platform.

so after short discussion with Noam Sheffer we decide that it will be nice to add this capability into Packet MEF.

in matter of fact i was able to add this new capability almost without having to change the Pocket MEF code at all.

in case that you are working on Windows CE solution and want to have MEF capabilities,

you can download it from the Pocket MEF space at codeplex.

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)