Importing .DLL everytime it has been updated, with MEF ???

Oct 13, 2010 at 10:36 AM

Hi ,

I am writing an extensible .NET 4.0 application, which will let end user to add new entities ( business objects , Forms etc ) in running application on fly. All new created entities will be part of X_Entity.dll (when ever user will add new entity in X_Entity.dll , I will compile this dll), which I want to reload in my main UI lets say Shell project , so I clearly dont want to add a reference of X_Entity.dll in my Shell project at design time . I have considered create new AppDomain and load X_Entity in it at runtime whenever it has been updated by user , but having issues of crossdomain communictaion. 

So I will appreciate any help from the MEF community , in guiding me that how can I use MEF to handle my problem .

Can MEF help me loading X_Entity.dll in my SHell project , every time its updated ?  

 

Thanks ,

DNET4

 

Oct 13, 2010 at 2:00 PM
Edited Oct 13, 2010 at 2:07 PM

> Can MEF help me loading X_Entity.dll in my SHell project , every time its updated ?

You cannot even change an assembly while it is loaded; you have no write access at that time. The only way to do what you want is to load the assembly in a separate appdomain, so that it can be unloaded.

It sounds like you are falling into the Inner-Platform trap (also featured on thedailywtf.com) . Unlimited customizability by the end-user may seem like a good idea to you now, but it never works well. Focus on making your code maintainable and reusable for other programmers instead.

Oct 14, 2010 at 10:30 AM

So incase of Extensible application which allows the user to add new views run time in separate assembly which is needed to be 'Import'(ed) again in main (Shell) application ,

What is recommended approach ?

And how MEF can help ? 

Thanks,

DNET4

Oct 18, 2010 at 3:05 PM

DNET4,

wcoenen may have a point about over engineering, but I'm assuming you probably have a good reason for trying this approach.

I found myself wanting to do virtually the same thing in a MVVM app.  You can acheive the recomposition you want as long as your willing to rename your assemblies when a new version comes available.  Ex. if you put your Extensions assemblies in a directory and link a Directory catalog to it, you will need to remove the old assembly (version 1) and then add the updated assembly (version 2) with a new assembly title.

 Note that assembly 1 is still loaded into memory, but since you removed it from the directory MEF will only catalog and compose parts in version 2.  You could load your extensions in a seperate AppDomain, but that can get tricky.  Unfortunately, MEF composable part base classes don't inherit from MarshallByRef object, which limits us from simplifying AppDomain scenarios.  If your interested in that though, my attempts are linked to in this link.

This person was asking a similar question to yours.  http://mef.codeplex.com/Thread/View.aspx?ThreadId=222650

-Nick