Click here to Skip to main content
12,548,842 members (54,117 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


3 bookmarked

Getting started with Multifile assembly – Part II

, 23 Jan 2013 CPOL
Rate this:
Please Sign up or sign in to vote.
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.

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

Sample Architecture Overview

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

Sample Architecture Overview from Visual StudioHere 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.

Layer Diagram

How does Sample Main Application looks ?

Main Assembly

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 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
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.
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.

// 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.

// 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)

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.



This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Harsh Baid
Software Developer TechAspect Solutions Pvt. Ltd.
India India
No Biography provided

You may also be interested in...


Comments and Discussions

-- There are no messages in this forum --
| Advertise | Privacy | Terms of Use | Mobile
Web01 | 2.8.161021.1 | Last Updated 23 Jan 2013
Article Copyright 2013 by Harsh Baid
Everything else Copyright © CodeProject, 1999-2016
Layout: fixed | fluid