Some brief before we continue

Hi! In the last article on this topic here MULTIFILE ASSEMBLY part – I, I had talked conceptually about creating multi-file assembly and possible usages.

In this post we will have more insights on the implementation part regarding multi-file assembly and using MEF to apply the concept practically in the applications using Directory Catalog technique.

Table Of Contents

• History on multiple file assembly
• What is MEF
• General Architecture of Extensible Application
• Implementing Windows Forms Application using MEF

History of multiple file assembly

To implement the multiple file assembly aka plugin application approach in past was very tedious work (I believe multiple file assembly is which uses more than one assemblies). Like in .NET application programs we had to use Reflection and Dynamic assembly loading and types tactics which were not reliable i.e. In case if any exception happens in the referencing assembly while loading into main program it would result in either a minor failure of a sub program or whole program leading to crash. However today we have a very good tool at hand from Microsoft, the name is Managed Extensibility Framework i.e. MEF in short name which I would be discussing in next few paragraphs.

What is MEF?

The answer is MEF is a composition layer or class library for .NET that improves the flexibility, maintainability and testability of applications of any size. MEF is used for third-party plugin extensibility, or it can bring the benefits of a loosely-coupled plugin-like architecture to our applications. It also lets extension or plugin developers easily encapsulate code and avoid fragile hard dependencies between the applications. In the next section we would be directly going to architecture overview and implementation information.

General Architecture of Extensible Applications

Here there are three major components

• Main Assembly
• Infrastructure Assembly
• Plugin Repository

Main Assembly

Main Assembly is comprised of UI and Wire Line or Skeletal code to combine the building block of the application. This defines the Features and Functional limits regarding extensibility of our application. Controlling the program flow and loading plugins from the repository such as from local directory or download from global repository and so on.

Infrastructure Assembly

In Infrastructure assembly, we have interfaces and abstract classes defined which stands for two purposes:

• Define the basic skeleton of the plugins assemblies which are to be plugged in the main application.
• Enables the loose-coupling and balanced cohesion between the main program and plugin assemblies.

We have to design and implement the Infrastructure assembly modules step before we start implementing the plugin modules, and design decisions are based on the features and extensibility of the application. It purely depends on the Infrastructure assembly that we do not have to recompile the main application assembly, in case of any changes to accommodate any new requirement or extensibility of the plugins into the Infrastructure assembly.

Plugin Repository

In Plugin Repository, we can have many different implementations based-on the Infrastructure assembly. Each and every plugin may or may not have all the types definition that we have in the Infrastructure design. The plugin repository can be online like Nuget Gallery and Atlassian JIRA or may be offline based on the needs of the application.

Implementing Windows Application using MEF

Here we have one visual studio solution named “DynamicAssemblyApp” and four projects in that:

• DynamicAssembly.Infrastructure – It is Infrastructure assembly.
• DynamicAssemblyApp – It is Main assembly.
• DynamicAssembly.FedEx – It is an Plugin assembly for FedEx specific shipping implementations.

DynamicAssembly.USPS – It is an Plugin assembly for USPS specific shipping implementations.

So how is this application loosely coupled and how plugins work in application ?

Here the layer diagram below shows the strong-coupling between the different assemblies. On closely inspecting we can observe that the Main Assembly aka DynamicAsssemblyApp does not have connector to any of the plugins we have created. We make it possible using the MEF to load the plugin assemblies at runtime into the infrastructure instance models in the main application’s memory.

How does Sample Main Application looks ?

As we click the Load Assembly button the application would lookup the plugin directory and load the different shipping methods into the main assembly and List them in the ListBox control placed on left-hand side.

Please note currently in MEF approach there is no easy way to unload the plugins once we have them loaded into memory as mentioned in one of the www.StackOverflow.com question here.

To understand the dynamism happening in the main assembly, I would like to show it in some steps as below

1. Define the Export or ExportMany in the plugin assembly on the class definition which inherits from IShipping type (Only those classes which inherits from Interface defined in Infrastruture assembly can be marked as Export, so application would know that where the plugin instance fits).
2. Define the location to load the dynamic parts into our application, i.e. a public variable or property of the Interface type from the Infrastructure assembly. Here is is IShipping type.
3. Define the trigger for loading the plugins such as
   • At the start up of main application in background thread so as to not slow down the startup time (recommended).
   • On click of a button or dropdown selection (shown in the example).
   • On File Directory changes with using some File System watcher.
4. After the trigger check the variable or property having the imports, and use in the application appropriately as per the requirements.

Please note: Import/ImportMany or Export/ExportMany can be based on three different ways

1. String Key i.e. [Export(“MyTypeKey”)].
2. Type Definition such as Interface i.e. [Export(typeof(IInterface))].
3. Both from above (recommended, As this will help to uniquely identify the Import happening in the main application and we can Import the target type in different forms from one plugin assembly and in less strict manner) i.e. [Export(“MyTypeKey”, typeof(IInterface))].

Defining Export in plugin based on the type.

/// 
/// Define the FedEx method for Shipping
/// 
// Export attribute here declares that the assembly is,
// ready to provide this class to external application to use
[Export(typeof(IShipping))]
public class FedExShipping : IShipping

We import the plugin instances for FedEx and USPS Shipping Methods in Property ShippingList in the main application and declaration is decorated with ImportMany attribute which would import and instantiate all the class types inheriting from IShipping interface from the plugin assemblies into the specified property.

// Defining the imports from the plugin directory.
// Using ImportMany as we would be loading all the assemblies,
// containing the Export for the specified interface type.
[ImportMany(typeof(IShipping))]
public List<IShipping> ShippingList { get; set; }

On click of the button ‘Load Assembly’ we trigger the loading of plugins assemblies from the plugin directory in the application directory. The code for this as below

/// 
// Clean up previous Shipping Methods.
lstboxShippingMethod.Items.Clear();

// Using the directory approach for pluging/loading the assemblies dynamically.
// DirectoryCatalog constructor takes the input filepath for the plugins
// Here it is in the application directory i.e. /bin/plugin/*.dll
var catalog = new DirectoryCatalog("plugin");

// Compose container using DirectoryCatalog instance
var container = new CompositionContainer(catalog);

// Finally load the plugins
// Here we might face exceptions in loading and exception information
// is usually in the InnerException of the Exception.
container.ComposeParts(this);

// If we found no Exports from the plugins for the Shipping Methods
// then return empty handed.
if (ShippingList == null) return;

// Iterate thru each of the shipping methods and add to the ListBox Collection
// PS: We could do many other sort of things with the Imported the Shipping List.
foreach (IShipping item in ShippingList)
{
	lstboxShippingMethod.Items.Add(item.ShippingName);
}

The NameSpace for ImportMany attribute and DirectoryCatalog are as below respectively,

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

So getting in action,

1. Rebuild the solution.
2. Rebuilding solution will copy the FedEx assembly in the main application plugin directory automatically, as it is coded in the plugin’s Post-Build commands (see in Project’s Properties) to copy it there in the plugin directory.
3. Execute the main application.
4. Click the ‘Load Assembly’ button.
5. FedEx would be listed in the ListBox.
6. Now copy manually the USPS plugin assembly (/bin directory contents) into the plugin directory.
7. One more time click the ‘Load Assembly’ button.
8. This time FedEx and USPS both would be listed in the ListBox.

And we are done with sample!

Download the sample application from SkyDrive here.

I hope this was pretty good to know & understandable regarding plugin applications and MEF. At the point now I think that I would publish the MEF version of the HB Code application in future.

Do comment below regarding what you think on plugin applications and using MEF.

Keep reading and keep your thoughts coming to the world out.

Some Recommended articles and questions regarding MEF and plugin applications.

• StackOverflow – How does MEF’s DirectoryCatalog work?
• CodeProject – An Introduction to Managed Extensibility Framework (MEF)
• MSDN – Managed Extensibility Framework (MEF) Overview

 

Related articles

• Preferences from for MEF plugin
• Plugin based development
• Implementing Chain of Responsibility Design Pattern in C# using Managed Extensibility Framework (MEF)
• Announcing the jQuery Plugin Registry
• Introducing ForTea – a T4 templating plugin for ReSharper
• Log4net cannot find configuration file when run from Visual Studio/Microsoft Test Framework

CodeProject