C# .NET 4.0 Forms plugins manager

Question

I'm a bit lost with MEF, MAF, Unity ...

This question is about architecture of Winform application.

I've got a main project which contains a Main form and some other forms;

Because i want to include modularity, i'm thinking of using a Plugin System.

What I would like to do is opening each Plugin Dll when the Main Application is opened to reference each with button, toolbar ...

Then i would like to dispose them until they are called.

But i don't want all the plugins to be kept in memory.. just to got a good architecture model.

So first about .NET : Does dotNet keep only a reference to the dll plugins in memory or all the plugin code ?

I'm thinking of using MEF with LAZY collection of Import, but i need to instantiate them first to get my buttons informations. So second question

If i set the Import Collection to null and lauch the compose() function again, the plugins will be load or wait until call to be load (lazy) ?

Answer 1

Then i would like to dispose them until they are called.

Instead of inspecting imported objects and then throwing them away, you should inspect the import metadata. You can get this metadata by importing Lazy<IFoo,IFooMetadata> or Lazy<IFoo,Dictionary<string,object>>. You can add this metadata to exports with the ExportMetadata attribute.

So first about .NET : Does dotNet keep only a reference to the dll plugins in memory or all the plugin code ?

Once an assembly is loaded it remains in memory, unless you unload the whole AppDomain.

Also, there are no out-of-the-box implementations of ComposablePartCatalog in .NET 4.0 which can be queried without loading the corresponding assembly. But in theory something like that could be done if you store the metadata somewhere outside the assembly. There is a sample of such an implementation in the MEF code on codeplex.

I'm thinking of using MEF with LAZY collection of Import

Using lazy imports will not necessarily prevent assemblies from being loaded. If you have a reference to a Lazy<IFoo> object, then at least the assembly containing IFoo has to be loaded. And as I explained above, the assembly containing the exported IFoo implementation will also have been loaded at that point.

Using Lazy will only postpone the invocation of some constructors, hopefully resulting in faster start-up of your application.