Click here to Skip to main content
15,867,686 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
Hi all,
I am dealing with MEF for quite a while now and was quite pleased with it.
Since now I used a DirectoryCatalog that loaded dll's following a specific naming convention (all dll's/exe's etc in the same folder).

Now I get the chance to structure something equal in a different way, because I somehow felt dirty in the past putting everything into a single folder.

I thought about having the following structure for the new project (I use [xxx] for folders):

[MainApplication]
...MainApplication.exe
...[lib]
......ContractsLibrary.dll
...[plugins]
......[HelloWorldPlugin]
.........HelloWorld.exe


MainApplication.exe contains the PluginManager, which iterates over the [plugins] folder and creates a DirectoryCatalog for each subfolder and then creates the related CompositionContainer.
It references the ContractsLibrary.dll in order to know about the contract that a plugin has to export.

HelloWorld.exe also needs to reference the ContractLibrary.dll in order to know about the contract it has to export.

During development both reference the ContractsLibrary.dll located in the [lib] folder having copy local set to false.

Actually the import doesn't work due to a FileNotFOundException that is thrown during composition of HelloWorld.exe (related to the ContractsLibrary.dll).
I solved this issue by implementing AssemblyResolve in MainApplication.exe that will use the ContractsLibrary.dll from the [lib] folder.

So this already sounds problematic, doesn't it?

Anyway, after having given this a try I am now searching for a more professional way to structure an application tha should be able to import plugins that share the same dll's (the ones in the [lib] folder).

What is a good way to structure a project fulfilling above mentioned needs?

If you have any questions regarding this question do not hesitate to ask and I'll try to clarify it...

Also, if you have a good read related to the topic at hand, just drop it in and I'll dig through it.

Any input is kindly appreciated,
best regards
Andy
Posted
Updated 11-Apr-12 3:18am
v2

1 solution

I have used MEF for a large medical system for sometime now. We also use a separate folder for the plugins. Actually we have multiple folders as well that various plugins are in.

The only difference that we have from your setup is that the contract DLL is in our main folder, not a lib folder. I did not mind the contract DLL being at the main folder level because it is something that it directly compiles against. This also saved me from having to change the AssemblyResolve as well. If your setup is way off-base then mine is as well. But at least you now know that another developer used pretty much the same ideas that you did (without the lib folder).
 
Share this answer
 
Comments
hoernchenmeister 11-Apr-12 11:01am    
Thanks Steve for taking the time to answer.
Good to know that I am not totally off with my ideas ;)
Honestly I wouldn't mind having the contract DLL in the MainFolder neither if I could get rid of the AssemblyResolve stuff (that just somehow feels "not right").

I am currently testing different setups to figure out which might suit me best. One of the main goals is still the reduction of duplicates in the plugin folders. Maybe our customers want to create plugins on their own, which should also be possible (at the end that's one big advantage of a plugin system). They will have to code against the contracts DLL and I am pretty sure there will be a copy in their plugin folder as well... which seems to be useless die to the FileNotFoundException that is thrown when resolving the plugin via the PluginManager of the MainApp.

We'll see what kind of inspirations this post will bring up...

Thanks again for your input Steve, it is very much appreciated.

best regards
Andy
Steve Maier 11-Apr-12 11:15am    
what I have found is that the folder with the plugins does not need the contract dll at all. The main app already has it loaded in memory, so those actually do not need to be there.

I converted our installer to WIX and removed all of the extra files and it is working really well for me.
hoernchenmeister 11-Apr-12 11:49am    
Yes, that's right. I can confirm that the contracts Dll is not necessary in the plugin folders.

I stumbled into another possible solution that worked (at least with the tests I am doing).
I added a <probing privatePath="lib"/> segment to my MainApplications config file.
This allows me not to use the AssemblyResolve because probing includes the lib folder now.
In my opinion both solutions behave somehow the same. One specifies a directory in a config, the other loads dll's from a directory in code...

It would be interesting to see what option is preferred by other devs.
Or even better how to overcome the need to do this :)

Thank you Steve for contributing :)
cheers
Andy
Steve Maier 11-Apr-12 14:18pm    
Thanks for the tip on <probing>. I did not know about that one.
hoernchenmeister 12-Apr-12 2:22am    
You are wellcome :)

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900