This project has moved and is read-only. For the latest updates, please go here.

Lazy loading and instantiation

Oct 5, 2008 at 10:14 AM
I've been reading about MEF with great expectations... and are eagerly waiting for the remaining chapters in the guide.
Until those chapters will be release is there any information about "Lazy loading and instantiation".

Oct 6, 2008 at 9:14 AM
Hi Lasse,

You may like to check out the 'Export' type (and the 'ExportCollection' type, which is its collection counterpart) for lazy/delay loading. Here is the basic idea. For example, you have

public Export<ILogger> Logger { set; get; }

Once composition completes, you can then use Logger.Metadata to access metadata of the export. However, the export is not instantiated until you call Logger.GetExportedObject(). There is another generic variant of Export (Export<T, M>) that supports strongly typed metadata.

Hope this helps and please let us know if you have more questions!

Oct 8, 2008 at 5:23 PM
Tanks for your answer.
I've tried to implement a ExportCollection<T,M> according to the FileExplorer example. Unfourtnatly seems the be some problems, the collection is always null.
But I am on to this. Any tips how to debug this?

If you put the Logger in a separate assembly .... I guess the assembly will be loaded when building metadata. Will the assemble then be unloaded to save memory.

Oct 9, 2008 at 5:42 AM
Edited Oct 9, 2008 at 5:51 AM
Regarding your first question, unfortunately, MEF cannot help too much here today. We are currently working on this to improve the debugging/diagnosis experience of MEF. You may like to post a small snippet of your imports/exports and we may be able to help to figure out what went wrong. (just a random guess - if your import/export is private/protected/internal, please make sure your assembly has the AllowNonPublicComposition attribute).

WRT the sencond question, yes, the assembly is loaded and unfortuantely again, the assembly cannot be unloaded due to CLR limitation. However, we are currently building a new catalog feature to support caching - assembly is loaded on the first run of the app to build cached metadata etc. and the assembly will not be loaded in the second time onwards if you do not need to instantiate anything from the assembly (metadata etc. will be loaded from the cache instead).

Thanks for your feedback!

Oct 9, 2008 at 3:17 PM
is the second answer similar to what I had posted earlier in the other thread with a drawing? Wouldn't it be better to have a cache server that holds the original instance and then sends a copy to the caller?
The cache server would then be responsible to instantiate the latest version / a predefined version of a class based on the request from the caller.

 It can also manage the life of the EOs( extensible objects).
for example,
some objects would need time based reload and some others would need a resuscitation. All of these can be handled by the cache server.
Oct 10, 2008 at 6:31 AM
Ganesh, we did not do this in a distributed way (I have forwarded your earlier post to our whole team and the feedback from our team member is that the current architecture of MEF should not prevent the distributed catalog you drew from being implemented by people). In current case, it is also the responsibility of catalog to maintain and update the cache when assembly changes.

Oct 10, 2008 at 6:48 PM

Hi again.
Changing my imprort to public did the trick. Tanks.. for all help.


Oct 10, 2008 at 9:11 PM
Happy to be helpful, Lasse and thanks for posting the results!