The document discusses the importance of plugin architecture in developing extensible software, emphasizing the open-closed principle which advocates for software that is open for extension but closed for modification. It outlines the use of Managed Extensibility Framework (MEF) and Managed Addin Framework (MAF) for implementing such architectures, detailing their features and differences. Additionally, it provides a use case scenario demonstrating a custom implementation that leverages both MEF and MAF to enhance application modularity and reliability.

1. Plugin Architecture
Leveraging the benefits of
Extensible Application Architecture

2. Extensible Application Architecture
 A very important principle of Application design is the Open-Closed Principle (ref S.O.L.I.D. principles of software design).
 The Open-Closed principle states that “Software entities (classes, modules, functions, etc.) should be open for extension, but
closed for modification”
 It is generally achieved by using abstractions, or by placing behavior(responsibility) in derivative classes.
 A truly Extensible Software design should allow 3rd Party/External developers to extend and enhance it further
even after they have been compiled and released.
 This is possible only if we design our application to be easily Pluggable.

3. Plugin Architecture
Plugin is any piece of software that extends or changes the behavior or interface of an existing, compiled application.
For the plugin to be able to extend the any application, the existing application must itself be designed so that its is Pluggable
(Implementing a Plugin Architecture).
Examples of applications having a plugin architecture are MS Office, Visual Studio, Eclipse IDE (Java)
Why/When do we need a Pluggable Application (Benefits)?
 To allow applications to be extended after they have been compiled and released.
 To allow other applications to be able to connect to and enhance your application
in a standard BUT isolated way.
 To make Unit testing easier for teams working on different modules/Plugins.
 When we are designing a solution which should accommodate disparate
requirements implemented by other vendors in the future.
Eclipse IDE platform Architecture

4. Building Extensible design in .NET
Microsoft .NET already provides us with a few tools and libraries in order for us to get started with designing Extensible
Architectures.
The most popular of them all are MEF and MAF. Both are exclusive to each other but can be used in a complimentary manner.
A feature-by-feature comparison is as under :
Managed Extensibility Framework (MEF)
Managed AddIn Framework (MAF)
Primarily focused on providing extensibility
Provides extensibility along with Isolation
All the extensions are loaded in to the same AppDomain as the
primary application
All AddIns are loaded in separate AppDomains.
Dynamic Discovery of Extensions
AddIns must be installed before use. No dynamic discovery.
Extensions cannot be unloaded at runtime
AddIns can be installed/uninstalled without affecting the
primary application.
The whole application might crash, if and extension has an
error/
Since the AddIns run in their own AppDomain, they do not
affect the primary application in event of error.
Easier to Implement
Costly in terms of time, effort and Complexity.

5. Plugin Architecture Use Case Scenario (MEF+MAF)
A custom implementation of a Plugin Architecture using useful features and principles from both MEF and MAF is as under :
 The initial Plugin discovery needs to be done using MEF as it supports dynamic discovery of assemblies of a known type in folder.
 There is Shared contract which is present in both the Host and the Plugin which assists in the Dynamic Discovery of Plugins.
 Info about the loaded plugins such as name, file path, version etc. are stored in a static in-memory collection to be used later.
 Plugins are loaded in their separate AppDomains (MAF Principle) as needed (using information from the static in-memory
collection), which makes it easy to Load and Unload them.
 Since Plugins run in separate AppDomains, they do not affect the Host application in the event of failure/exception.
 The communication between AppDomain is a Custom implementation and is achieved using remoting (MarshalByRefObject)
 The Plugin Architecture extends to the Plugins as well. Meaning a Plugin itself can also be a Host to other Plugins.

6. Plugin Architecture Use Case Scenario …continued
Illustrated below is a custom implementation of a Plugin architecture.
 Each one of the modules (Plugins) below in boxes work independent of each other and communicate via a custom implementation of Remoting.
WCF Service (Hosted inside Windows Service)
Service A
[Plugin]
Service
Application
Service B
[Plugin]
WPF Application UI
Duplex
Communication
[WCF NamedPipes]
UI Application (Shell.exe)
[Plugin Host]
[Plugin Host]
Plugin Y
[Plugin]
[Plugin Host]
Plugin X
[Plugin]
Service C
[Plugin]
Future Service
[Plugin]
Application 1
[Plugin]
Application 2
[Plugin]
Plugin Z
[Plugin]
Future App
[Plugin]

7. Glossary
Term
Description
Plugin
A piece of software that extends or changes the behavior or interface of an existing, compiled application
PluginHost
A Pluggable application which can be extended using Plugins.
AddIn
A piece of software that extends or changes the behavior or interface of an existing, compiled application (same as Plugin)
MEF
Managed Extensibility Framework (http://msdn.microsoft.com/en-us/library/dd460648.aspx)
MAF
Managed AddIn Framework (http://msdn.microsoft.com/en-IN/library/bb384200.aspx)
AppDomain
The logical and physical boundary created around every .NET application by the Common Language Runtime (CLR) to isolate
applications from each other (http://msdn.microsoft.com/en-IN/library/2bh4z9hs.aspx)
Remoting
A means to establish Inter-process communication within the same machine
(http://msdn.microsoft.com/en-us/library/kwdt6w2k(v=vs.71).aspx)
WPF
Windows Presentation Foundation – Used to create Rich Client Applications
(http://msdn.microsoft.com/en-IN/library/ms754130.aspx)
WCF
Windows Communication Foundation – Used to create highly scalable and flexible services (http://msdn.microsoft.com/enus/library/ms731082.aspx)
Named Pipes
A mode of communication used by WCF to established Inter-process communication on the same machine.

8. A solution based on Plugin Framework might be
considered as Extreme Extensibility and is not
Extensible
Applications
the way to go for every software design.
A Plugin architecture is expensive to implement
and must be decided after much thought.
Refer the link below to learn more.
Find out more about implementing a Plugin Framework with MEF and/or MAF
(Click the above link in Slide show mode)