Choosing what to load [and when to unload]

Nov 12, 2008 at 8:28 AM
Hi

I have a basic MEF app working using a collection Import to import a number of Exports.
My plan is to list all available plugins and let a user select which ones they want to use.
I realised though that I saw no information as to how these plugins are loaded and their lifetimes.

Are plugins only loaded once they are first used, so if i never actually try use them they wont be instantiated? Or are they loaded at the Compose phase?  If a user decides they no longer want to use a plugin, how would you then unload it?

Thanks
Chris
Nov 12, 2008 at 10:54 AM

In the current bits, they load all the time, however soon we will be shipping our Catalog caching mechanism. One we do, assemblies will only load when they are composed. We also support lazy loading, where you compose a part that has dependencies which will be loaded in a  lazy loaded manner. To do this you would import using Export or ExportCollection. For example…

    [Export]

    public class LazyLoad

    {

        [Import]

        public Export LazyFoo { get; set; }

    }

And

    [Export]

    public class LazyLoadCollection :

    {

        [Import]

        public ExportCollection LazyFoos { get; set; }

    }

In both cases above, IFoo is not instantiated at composition time. Export contains a GetExportObject method, which at the time of calling will load the assemblies if they are not loaded (not in our current bits) and instantiate the instances.

You can also decorate your exports with metadata to allow them to be self-describing. The Export carries a metadata collection which you can inspect.

Regards

Glenn

From: m0nkeymafia [mailto:notifications@codeplex.com]
Sent: Wednesday, November 12, 2008 1:29 AM
To: Glenn Block
Subject: Choosing what to unload [and when to unload] [MEF:39743]

From: m0nkeymafia

Hi

I have a basic MEF app working using a collection Import to import a number of Exports.
My plan is to list all available plugins and let a user select which ones they want to use.
I realised though that I saw no information as to how these plugins are loaded and their lifetimes.

Are plugins only loaded once they are first used, so if i never actually try use them they wont be instantiated? Or are they loaded at the Compose phase? If a user decides they no longer want to use a plugin, how would you then unload it?

Thanks
Chris

Read the full discussion online.

To add a post to this discussion, reply to this email (MEF@discussions.codeplex.com)

To start a new discussion for this project, email MEF@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Nov 12, 2008 at 1:28 PM
Ok thats fine so long as I know how it does things, the plugins aren't memory intensive so at the moment thats ok.
Good to know your woking on Lazy Loading / Caching. 

I guess you have no ball park dates for a 3rd preview?

P.s. is this likely [or possible] to go into the .NET4.0 release?
P.p.s Why is my email address listed in your last post? Any chance you could edit it please?

Thanks
Chris
Feb 9, 2009 at 2:07 PM
Hi,
I tried MEF and I had a similar problem. More specifically:
Is it possible to "control" the behaviour of a "part"? I mean: If I want that a part can access only the exports available from some loaded assemblies and NOT from other that, although available in the folder (and then in the catalog), are not yet loaded (because I want to decide which assemblies are in memory in a given time), is it possible to deny the parts to use the container to load other assemblies?
From my understanding this system considers all the parts at the same lever and what is missing is instead a host figure that controls "when" each object can be instantiated. Is this correct?

Thanks

Feb 9, 2009 at 7:25 PM
@gnurg,
IMO, this should not be the work of the MEF. The ability to access or allow access should be the part of the class. There can be several ways to implement this. The durable one being a lookup table in a database that gets an update for each user.

Accessibility issue is something I had talked in some of my previous posting. Bloating the Memory with unwanted dlls is another. From the response from the development team I understand many of the issues are unique to each application. MEF is more a feature than a closed product, and as is should not go into the functionalites of a corporate environment.
Feb 10, 2009 at 7:54 AM
Thanks for the answer :)
But when you say: "The ability to access or allow access should be the part of the class."
Do you mean the "host" or the "part" class?
What I specifically mean is that, if a part (externally developed) writes something such as:

[Import]public IEnumerable<IMessageSender> Senders {get; set;}
how can I avoid that this instantiates an object for each class in the catalog that export "IMessageSender"?
Imagine that in the catalog there are 10 parts that export such an interface, but in that moment I want only 5 of these to be available (maybe because previously "activated" by the main app).
So, in a similar scenario, is it possible to "decide" (at host level) what "exports" a part can use?
I thought about building an "ad-hoc" catalog, but then what happen if I want to remove a shared instance? I read that in that situation the only way is to dispose the container, but if I do that, then all the instances created by this container will be disposed (and not only the one that I would like to remove), is this correct?

Regards

Feb 10, 2009 at 1:19 PM
@gnurg
I do not use MEF in any of my project as of now. I do a variant of this in a older .net version.

When I said the ability access should be part of the class, I meant that with MEF instantiating all classes , the ability to effectively access a class should be built into the class itself. For example, I would make property based access to the instance and in each property will check if an access can be given at all. All public methods will have the same logic. This is a overkill but that is the only way I can think of to restrict or provide accessibility to an instance of an MEFd class.