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

What's this all about?

Jul 13, 2010 at 1:16 PM
Edited Jul 13, 2010 at 1:25 PM

Hi People!

I’ve just come across this thing and still have some trouble understanding it, maybe someone can help me?
We currently have our own (non-MEF) plugin architecture and I’m unsure about whether to replace it.
This is what we’ve got:

  • Our own plugin architecture enables us to use .NET assemblies from VBscript.
  • There is a directory structure on a network drive like
    • AddOn1\ALPHA.TargetProject.username\AddOn1.dll
    • AddOn1\BETA.TargetProject.ALL\AddOn1.dll
    • AddOn2\FINAL.ALL.ALL\AddOn2.dll
    • Plus some support files
  • There’s a “resolver” that takes
    • the AddOn-Name,
    • the name of the target project,
    • whether it’s a production or test project
    • the username
      and then finds the best version of the AddOn and returns the full name of the dll
  • There’s a “loader” that takes the full name of the dll, reads it into a byte array, loads the assembly (the byte array prevents locking issues when replacing assemblies) and returns a default object.

What we want to change:

  • We anticipate that AddOns will be hosted by .NET instead of VBscript. For a some time they will run in parallel.
  • Right now there’s only three levels of hierarchy:
    • The host (file system, fine)
    • The AddOn (file system but custom loader, ok)
    • Any assemblies (created by us by us) the AddOn references in the GAC (bad, because of admin and update issues. We manage a large pool of PCs).

We’d like to get rid of the custom loader and the GAC, allowing deeper nesting of AddOns.

What we want to keep:

  • The directory structure.
  • The ability to replace assemblies on disk (that is, network drive) without being prevented by the assembly already loaded somewhere.
  • The ability to have VBScript host AddOns. This will probably still require a custom loader, properly installed in the GAC as registered COM component, but that can’t be helped.

So, do you think that this is something MEF can do?
Btw, can composable parts be used with COM Interop attributes too or are there conflicts?

Ideally we'd like for our parts to be .exe files that can be used as console applications, ComposableParts and and VBScript-usable COM components too. Can .exe files have exports too? Can a ComposablePart import an .exe file?