For the Nth Time, the CLR Has Its First Plugin Model

Posted by Jonathan Allen on Jul 21, 2009

Sections

Development

Topics

.NET ,

Programming ,

Managed Extensibility Framework ,

System.AddIn

Share |

RELATED Research

In honor of MEF reaching its feature complete milestone, we take a look at the confused story of extensibility in the .NET Framework. MEF or Managed Extensibility Framework is the fourth extensibility framework to be released by Microsoft. Though like all the previous times, Microsoft is claiming that it is the first.

The Managed Extensibility Framework, or MEF, is the official dependency injection framework for the .NET Framework. In the documentation they claim,

MEF presents a simple solution for the runtime extensibility problem. Until now, any application that wanted to support a plugin model needed to create its own infrastructure from scratch. Those plugins would often be application-specific and could not be reused across multiple implementations.

But that is not true. In addition to the third-party frameworks like Spring.NET, there are at least three other extensibility frameworks for the .NET runtime just among developed by Microsoft itself.

• Unity, which is sort for the Enterprise Library Unity Application Block
• The Composite Application Library, which is specifically for WPF and Silverlight Applications
• The CLR Add-In Model, also known as the MAF

So which to use? Glenn Block writes about this,

System.Addin is a great technology for addressing issues around versioning resliance, isolation and recoverability.

• Using System.Addin allows you to host different components in separate app domains, thus allowing those addins to have different versions of assemblies which they reference which all run in the same process.
• System.Addin allows you to separately version Addins so that you could have two versions of an Addin sitting side by side.
• System.Addin manages automatically unloading app-domains they are no longer used thus allowing you reclaim memory.
• System.Addin has a bunch of security infrastructure (addins run in a sandbox) to ensure that components that are loaded do not have unauthorized access to data in the rest of the app.
• System.AddIn allows your app to gracefully recover whenever one of the addins crashes (this is due to isolation)

MEF on the other hand is a great technology for discovery and composition

• MEF composes deep object hierarchies of components
• MEF abstracts components from static dependencies.
• MEF can allow components to be lazily loaded and lazily instantiated.
• MEF provides a cataloging mechanism and rich metadata for components to allow them to dynamically discovered.
• MEF can compose components from various programming models, it is not bound to static types.

Rather than simply build MEF on top of the Add-In Model, which they admit has some significant advantages in terms of isolation for security and stability, MEF seems to have been built from scratch with little or no consideration for the preexisting technology.

The confusion over the two technologies suggests that there are some disputes within Microsoft. On one side we are seeing videos with titles such as Creating Extensible Applications with the Managed Extensibility Framework. In November the Program Manager Gleen Block was even claiming that, “MEF is being position as the framework for extensibility going forward”.

On the other side, we have diagrams presented by Krzysztof Cwalina in June of 2008 clearly show MEF being used in conjunction with the Add-In Model. And the Program Manager Nicholas Blumhardt has said that interoperability between the two projects would be considered after .NET 4 is released.

One possible explanation for this is that the Add-In Model just doesn’t work for most people. It is an embarrassingly complex framework and code generation tools such as the System.Addin Pipeline Builder are needed just to get started. And it should be noted that this is the second incarnation of that project. It was forked from the original because it wasn’t being maintained and bugs were not being fixed.

So what will be the final fate of System.AddIn? With no one willing to say otherwise, it seems like it will be quietly abandoned just like LINQ to SQL.

1. Back to top

   some misunderstandings?

   by Stefan Wenig

2. - IoC and addins are two very different things. I don't see a conflict between Unity and MEF.
   
3. - The Composite Application Library is even further from the other two.
   

   Maybe they could/share some code, but that's beside the point.
   
   

   There really are some unanswered questions about the future of System.AddIn and its relationship to MEF. I think that's bad enough, no need to exaggerate the story.
   
   BTW, has LINQ to SQL really really been "abandoned"? The official version was that they just didn't want to extend LINQ to SQL until it matches EF, ending up with two libraries adressing the same problem (very much what you're criticizing here). They'd rather have a lean-and-mean LINQ provider with very basic ORM capabilities (LINQ to SQL) and a full ORM for enterprise apps (EF). This makes a lot of sense to me.