Long time no see!

So it’s been an awfully long time since my last post, and I’m aiming to bring my blog post entries up to speed with my everyday workings and discoveries – So with that I’ll introduce my most recent GitHub project.

This project is aimed at people who’ve been looking at utilising MEF (Managed Extensibility Framework) but are overwhelmed with the amount of refactoring that would be involved to implement it. 

As with any framework, you need to weigh up the pro’s and con’s of each solution, and compare many solutions to find the closest fit to your needs. I think it’s naive for anyone to think that a single framework would cover their project’s every need, but by matching a framework as close to your requirements as possible means that bridging the gaps is a relatively small cost. Especially when you compare to to refactor hell to make your application fit the framework.

One other thing – If you’re starting a new project, this whole post may be irrelevant as you have the freedom to make the design choices when orchestrating your application. Whereas a LOB (Line of business) application that is mature, or a project that has limited staff resources may struggle and so I’m going to introduce a more simplistic choice for anyone that may need it.


I’m sure that you’ve heard many people before use new and trendy development buzz words like SoC (Separation of Concern), or Loosely/Tightly coupled. Though these words have been trending recently, their core concepts have actually been in the minds of developers for decades. 

Q. What is a ‘loosely coupled’ system? Loosely couple first off is not an innuendo though I would welcome a few laughs/suggestions in the comments. I will instead steal the wikipedia definition of the term because I think it’s the clearest explanation without getting into technicalities of development:

In computing and systems design a loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components.

Q. How does loose coupling relate to SoC? Hopefully if you’re a programmer you’ll notice that by the definition of loose coupling it almost enforces a Separation of concern. By loosely coupling components when you develop them, you will ensure that components are only dealing with the process they are contained to, and there is no dependency leaking.

Plugins are the best form of SoC

That’s a pretty bold statement I agree, but by physically separating the functionality to a plugin architecture you’re fully separating your business logic with a clear and concise boundary. By having such a clear boundary you’re enabling your application to not worry about the specifics of something like, for example, calculating a shipping cost.

There are of course some draw backs to this, by having such a large boundary you can create some tight dependencies due to the way the .NET framework is composed.

There used to be a namespace of System.AddIn but this is no longer the Microsoft recommended route of implementing plugins – they instead recommend the MEF which can be difficult to bolt on to an existing mature product. 

By utilising a dynamically invoked external assembly (DIEA – Yeah I actually just made that up!) you can implement specific endpoints of OO code with a single line of plugin implementation rather than refactoring your whole class to fit an MEF system.

The drawbacks

Unfortunately this is a difficult thing to get a good example of, but I’ve put up my solution on GitHub that will allow you to get a basic working example. It’s already defeated the main issue with dynamic assemblies, by using CrossDomainMarshalling.


  1. It allows us to instaniate our assembly in a different AppDomain, which means that if they’re any fatal errors in the plugin, it doesn’t bring your whole application down. Just the AppDomain it was loaded into.
  2. It allows us to only hold a lock on the assembly for the lifetime of the secondary AppDomain, rather than the entire lifecycle of the application.
  3. Lastly, it allows plugins to be invoked which reference different versions of 3rd party components (such as NLog)

When you’re done with your plugin, you simply unload the AppDomain you created and all the tear-down is done by .NET to release assembly locks meaning you’re able to update these plugins from within your own application without having to shut down.

Please take a look at the code on GitHub and if you have any feedback or suggestions I’m always eager to learn from others experiences.