# Tuesday, 16 June 2009

Episode 29

Berlin software developer Ziad Hakim recently completed his first iPhone application. In this interview, Ziad discusses his application and the process of developing for the IPhone.

12 mins, 18 secs

 

Tuesday, 16 June 2009 03:10:41 (GMT Daylight Time, UTC+01:00)
# Monday, 15 June 2009

In previous articles, I showed how to create a simple MEF contract based on a string and a contract based on an Interface.

Recall that MEF uses a contract that matches Import and Export components at runtime.  Contracts are defined by Import and Export attributes applied to declarations and definitions, respectively.

In this article, I'll show how to add metadata to your export data and to read that metadata at runtime.

We'll start with the sample created in my article about Interfaces.  In this sample, we created three projects:

  • MEFInterface contains the IToDo interface.
  • MEFConsoleApp1 is our console application.  It contains the Import property based on the IToDo interface.
  • MEFComponent1 is a class library containing an exported property implementing the IToDo interface.

We can add metadata to an Export with the ExportMetaData attribute.  The ExportMetaData attribute accepts two parameters: the name and the value of metadata applied to that export.  When MEF imports this export, the metadata is imported as well and is accessible from code.  Below is an Export from our sample with the ExportMetaData attribute applied.

    [Export(typeof(IToDo))]
    [ExportMetadata("Priority", 2)]
    public class FirstTask : IToDo
    {
        ...
    }

We apply a similar attribute to the other Export in MEFComponent1

    [Export(typeof(IToDo))]
    [ExportMetadata("Priority", 1)]
    public class ImportantTask : IToDo
    {
        ...
    }

MEFConsoleApp1 contained an Import that declared a collection of IToDo objects. To access the metadata of this collection, we should change the declaration to an ExportCollection. An ExportCollection implements the IEnumerable interface, but also exposes MEF metadata.

        [Import(typeof(IToDo))]
        public ExportCollection<IToDo> ToDoList { get; set; }

The code telling MEF to match up contracts remains the same; but the code to access the data and metadata changes to loop through the ExportCollection, as shown below.

            foreach (Export<IToDo> exTd in ToDoList)
            {
                IToDo td = exTd.GetExportedObject();
                Console.WriteLine(td.TaskName);
                int priority = Convert.ToInt32(exTd.Metadata["Priority"]);
                Console.WriteLine("Priority=" + priority.ToString());
            }

In the above code, exTd is an Export object.  The Export object contains not only the IToDo object we imported (via the GetExportedObject method); it also allows us to retrieve metadata.  Since metadata is a set of name-value pairs, we can retrieve a value by passing the name to the Metadata collection.  In this case, we pass get the value of Metadata["Priority"].

In this article, we showed how to apply metadata to an MEF Export and how to retrieve that metadata at runtime.

Code: MEFDemo3.zip (574.93 KB)

Note: The code in this article uses MEF CTP 5.

MEF
Monday, 15 June 2009 12:10:38 (GMT Daylight Time, UTC+01:00)
# Saturday, 13 June 2009

In my last article, I showed how to create a Managed Extensibility Framework (MEF) contract using the [Import] and [Export] attributes.  The code in that article created a contract based on a string and imported only a string variable.  I chose that sample because it was the simplest I could think of to illustrate the concepts of a contract.  But if all you are doing is swapping strings at runtime, there are simpler ways to accomplish this than MEF.

In this article, we will create a contract based on an interface.  Interfaces describe public properties and methods of a class without providing any implementation of those properties and methods.  This gives developers the flexibility to decide later which class to instantiate.  With MEF, that flexibility is increased even more because developers do not need to set a reference to classes at compile time.

Recall that MEF uses a contract that matches Import and Export components at runtime.  Contracts are defined by Import and Export attributes.

In our sample, we create three projects:

  • MEFInterface contains the IToDo interface.
  • MEFConsoleApp1 is our console application.  It contains the Import property based on the IToDo interface.
  • MEFComponent1 is a class library containing an exported property implementing the IToDo interface.

MEFConsoleApp1 and MEFComponent1 each have a reference to MEFInterface because each contains a class that implements the IToDo interface.  However, MEFConsoleApp1 does not contain a reference to MEFComponent1, even though the console app will consume classes in the class library.  An MEF contract replaces the tight coupling of a typical application.

Creating the Contract 

To accomplish this, we do the following
1. Create the IToDo interface in the MEFInterface project.  This interface defines two properties: TaskName and HoursRequired, as shown below

    public interface IToDo
    {
        string TaskName { get; }
        double HoursRequired { get; }
    }


2. In the console application, declare a variable of type IToDo and decorate this variable with the Import attribute.  The Import attribute accepts a parameter that defines the contract.  Assign the contract type of the import attribute as TypeOf (IToDo) as shown below

        [Import(typeof(IToDo))]

public IToDo MyTask {get; set;}

3. In the MEFComponent1 project, create a class that implements IToDo.  Return a value from each property's getter and decorate this class with the Export attribute.  Assign the contract type parameter as TypeOf(IToDo).  We now have a contract because we have an import and an export with the same contract parameter.  MEF will match these up when we tall it where to compose its parts.

    [Export(typeof(IToDo))]
    public class FirstTask : IToDo
    {
        public string TaskName
        {
            get
            {
                return "Get out of bed";
            }
        }
        public double HoursRequired
        {
            get
            {
                return .10;
            }
        }
    }

4. As in the code from the last article, we must tell MEF where to find all the parts to compose.  Add the following code to the MEFConsoleApp1.

            string folderToWatch = 
System.Configuration.ConfigurationSettings.AppSettings["MEFExportFolder"];
var catalog = new DirectoryCatalog(folderToWatch); var container = new CompositionContainer(catalog); var batch = new CompositionBatch(); batch.AddPart(this); container.Compose(batch);

5. The above code gets the folder location from App.Config file, so you will need to add to the MEFConsoleApp1 project an application configration file with the following contents. (Set the directory to the location of the compiled DLL for the MEFComponent1 project).

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <appSettings>
    <add key="MEFExportFolder"
         value="C:\Development\MEF\DGCode\MEFDemo2\MEFComponent1\bin\Debug" />
  </appSettings>
</configuration>

6. Finally, add code in MEFConsoleApp1 to output values of our variable.

            Console.WriteLine
(
string.Format
(
"It takes {0} hours to do the task: {1}.",
MyTask.HoursRequired,
MyTask.TaskName
)
);

What if there are Multiple Exports matching an Import? 

In this case, MEF was able to match a single IToDo Export with a single IToDo import. But what would happen if MEF found two Exports to match just one import? 

In our example, we might add to MEFComponent1 a second exportd class that implements IToDo.

    [Export(typeof(IToDo))]
    public class ImportantTask : IToDo
    {
        public string TaskName
        {
            get
            {
                return "Make the donuts";
            }
        }
        public double HoursRequired 
        { 
            get
            {
                return .25;
            }
        }

Which Export would MEF choose to match the Import?  Both satisfy the contract.  The answer is that MEF would choose to throw an exception.  If we can't be sure of how many Exports MEF will find to match our Import contract, we should replace our IToDo declaration with an collection of IToDo objects for the Import, as shown below.

        [Import(typeof(IToDo))]
        public IEnumerable<IToDo> ToDoList { get; set; }

Then, we can loop through this collection and output all the properties:

            foreach (var td in ToDoList)
            {
                Console.WriteLine
(
string.Format
(
"It takes {0} hours to do the task: {1}.",
td.HoursRequired,
td.TaskName
)
); }

In this article, we showed how to create an MEF contract based on an interface and how to handle mutliple exports for a single import in an MEF contract.

Code: MEFDemo2.zip (574.36 KB)

Note: The code in this article uses MEF CTP 5.

MEF
Saturday, 13 June 2009 04:19:00 (GMT Daylight Time, UTC+01:00)
# Wednesday, 10 June 2009

Microsoft Managed Extensibility Framework (MEF) is a framework for building applications composed of parts.  By constructing an application of parts, any part can be replaced at runtime. 

In order to use this framework in your project, you will need to set reference to System.ComponentModel.Composition.dll (which you can download from http://codeplex.com/MEF) and add the following statements to the top of any module with MEF code or attributes

using System.ComponentModel.Composition;
using System.ComponentModel.Composition.Hosting;

The composition of MEF parts is very loosely coupled.  Coupling occurs using contracts.  A contract consists of an Import and one or more Exports.

An Import is a place in your application that defines a variable but does not explicitly state how that variable is implemented.  Instead, a declaration is decorated with the [Import] attribute.  A parameter of the [Import] attribute describes the implementation that the variable is seeking.  This parameter can be a string, a type or an interface.  When MEF encounters an Import, it looks for an Export that matches the Import's contract parameter.

An Export is a class decorated with the [Export] attribute. This attribute tells MEF that the class is available to satisfy any matching Import request.  Just as with the [Import] attribute, the [Export] attribute accepts a parameter that is a string, a type or an interface.

For example, the following variable declaration

        [Import("MyMEFString")]
        string SomeString { get; set; }


defines an import with a contract "MyMEFString". That contract is satisfied by the following export

        [Export("MyMEFString")]
        string ThatExportedMefString
        {
            get
            {
                return "This string was provided by an MEF contract.  It is from  an external assembly.";
            }
        }

Simply declaring this contract isn't enough.  We need to tell MEF to match up the imports and exports.  The following steps are necessary for MEF to do its thing
1. Create a catalog.  A catalog tells MEF where to find the Imports and Exports.
2. Create a container that uses the catalog.
3. Create a batch and call the Compose method of that batch.  The Compose method tells MEF to find the Imports and Exports that make up each contract and match them up.

If you want to compose parts that all exist in the currently executing assembly, this is done with the following code

 var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
var container = new CompositionContainer(catalog);
var batch = new CompositionBatch();
batch.AddPart(this);
container.Compose(batch);

The code above assumes that the contract's Exports and Imports are in the same project. 

Notice the first line of code, in which we declare a variable named 'catalog'.  This line instantiates a Catalog object.  A Catalog object defines where MEF looks for parts.  MEF supports the following types of Catalogs 

  • An Assembly Catalog retrieves MEF components compiled into a given assembly.
  • A Directory Catalog retrieves all MEF components in all assemblies in a given directory.
  • An Aggregating Catalog is used when you want to retrieve MEF components from multiple places - for example, from a specific assembly and from a directory; or from two different directories.

Of course it doesn't make much sense to go to the trouble of using a loosely-coupled framework like MEF and getting your parts from the current assembly. In fact, it often doesn't make sense to get parts from an assembly that is known at design time.  If we know the assembly name and location, we might as well set an explicit references to it.

A more likely scenario is to import all MEF assemblies found in a specific folder. To do this, we use a Directory Catalog.  We replace the declaration/initialization of the catalog with the following line

 string folderToWatch = @"C:\Development\MEF\DGCode\MEFDemo1\MEFComponent1\bin\Debug";
var catalog = new DirectoryCatalog(folderToWatch);

By setting our catalog to a DirectoryCatalog, we tell MEF to search for imports in all assemblies found in a well-known folder.  We can just drop DLLs into this folder and MEF will find them and use them at runtime, even if our projects do not set a reference to them.

The MEFDemo1 solution is a very simple sample that uses this code. 

In MEFDemo1, a console application declares a string variable named "SomeString" which is decorated with the Import attribute and defined by the contract "MyMEFString". 

At runtime, MEF determines the The value of SomeString by searching for the Export half of the contract.  It finds it in ThatExportedMefString variable, declared in the Class1 class of the MEFComponent1 project.  MEF knows to look here because we pointed a DirectoryCatalog at the folder where MEFComponent1.dll is compiled.  (If you copy this solution to a different directory, you will need to change the path defined in folderToWatch and recompile the MEFComponent1 project. In a real-world application, we would probably pull the folder name from a configuration file or otherwise set it at runtime to make it even more flexible.) 

The important point is that we don't need to set any references between these projects in order for them to communicate.  The contract and MEF take care of this for us.

In this article, we showed a very simple MEF contract, based on a string.  In the next article, we'll show how to create a contract based on an interface.

Code: MEFDemo1.zip (563.48 KB)

Note: The code in this article uses MEF CTP 5.

 

MEF
Wednesday, 10 June 2009 11:43:53 (GMT Daylight Time, UTC+01:00)
# Monday, 01 June 2009

Episode 28

In this interview, Aydin Akcasu describes how to use Microsoft .Net to write applications that interface with the remote controller for the Wii game console.

13 mins, 8 secs

Monday, 01 June 2009 12:23:57 (GMT Daylight Time, UTC+01:00)
# Saturday, 30 May 2009
 #
 

Microsoft Managed Extensibility Framework (MEF) is a framework for building extensible applications. Using MEF, you can build extensible applications constructed of loosely-coupled composable parts.  By constructing an application of parts, any part can be replaced at runtime, without recompiling or redeploying the entire application. 

One use would be to create an extensible application with a plug-in architecture, allowing users to extend it or to replace parts of it, without recompiling.  As such, you would not need to release the source code along with your application. 

Microsoft already has several technologies to accomplish similar things.  Visual Studio 2008 and Microsoft Office 2007 each has a plug-in framework that allows users to extend the application.  MEF promises a single extensibility framework that can be used across all Microsoft applications.  This frees developers from the need to learn a different framework to extend each application.  In fact, the editor in the upcoming Visual Studio 2010 (now in beta) is built on top of MEF, so that developers can use MEF to add plug-ins to the IDE.

Of course, there are simpler technologies built into the .Net framework that allow you to extend applications at runtime. 

In the current version of .Net, we can code to interfaces, instead of concrete classes.  Doing so gives us the ability to defer to runtime which class to instantiate.  Our code is flexible enough to accept any class, as long as that class implements the expected interface.  However, we must decide at compile time all possible classes that might be instantiated at runtime.  This is because, in most cases, we cannot instantiate a class without setting a reference to the assembly in which that class resides.  And setting references is something done prior to compiling.  Using MEF, we can instantiate classes even if there is no explicit reference set.  MEF takes care of that for us.

Managed Extensibility Framework promises to solve the problem of building loosely-coupled, extensible applications without forcing developers to learn a new skill set for each application.  It does so without the disadvantages of forcing a recompile and loading classes into memory unnecessarily when an application is extended at runtime.

Note: As of this writing, MEF is in Community Technology 5 and is planned to be released as part of .Net 4.0

.Net | MEF
Saturday, 30 May 2009 18:35:37 (GMT Daylight Time, UTC+01:00)
# Thursday, 28 May 2009

Episode 27

In this interview, Microsoft Developer Evangelist Jennifer Marsman describes Windows Azure and tells how to get started developing applications using this platform.

14 mins, 35 secs

Thursday, 28 May 2009 06:36:05 (GMT Daylight Time, UTC+01:00)
# Monday, 25 May 2009

Episode 26

Microsoft MVP Chris Woodruff is one half of the team of "Keith and Woody" that host the popular Deep Fried Bytes podcast. In this interview, Chris talks about why they started this podcast and what makes it different.

17 mins, 58 secs

Monday, 25 May 2009 18:22:19 (GMT Daylight Time, UTC+01:00)
# Wednesday, 20 May 2009

Episode 25

Mike Hacker is the Practice Director for the Sogeti Michigan Microsoft Practice, which makes him my boss.

In this interview, Mike describes issues around single sign-on.

21 mins, 21 secs

Wednesday, 20 May 2009 12:42:16 (GMT Daylight Time, UTC+01:00)
# Tuesday, 19 May 2009

SPEAKING

I am scheduled to speak at the following upcoming events

CodeStock 2009

The CodeStock conference will be held in Knoxville, TN on June 27.  I will be presentingon Microsoft Managed Extensibility Framework (MEF).  You can find information on this event and register at http://codestock.org/

West Michigan .Net User Group

I will speak again on MEF at the July 14 meeting of the West Michigan .Net User Group in Grand Rapids.  You can find more information at http://www.wmdotnet.org/

LISTENING

I'll quietly spend all of Wednesday May 20 at the Microsoft office in Southfield so that I can attend a series of events throughout the day.  The details are below:

ArcReady
Time: 9:00-11:45AM
Topics:
Trends and patterns on the client tier
Applying Microsoft technology on the client tier
Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032408649
 
MSDN Unleashed
Time: 1:00-3:00PM
Topics:
Internet Explorer 8 for Developers
Developing on Microsoft Windows 7
Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032409548
 
Technet Unleashed
Time: 3:10-5:00PM
Topics:
Windows Server 2008 R2 – Optimize Your Time
Windows 7 – Maximize Your Potential
Register: http://msevents.microsoft.com/CUI/EventDetail.aspx?culture=en-US&EventID=1032410548

Southeast Michigan .Net User Group
Time: 3:10-5:00PM
Topic: RIA
More information:
http://migang.org/

 

Tuesday, 19 May 2009 18:13:25 (GMT Daylight Time, UTC+01:00)