Take the 2-minute tour ×

I got an application that load plugins via MEF.

The application is running in several instances on a terminal server.

When I need to test a new plugin in the production environment I redirect MEF to another folder. The problem is that sometimes the assemblies are loaded from the original folder even after redirection. It does not happen every time and I can not reproduce it on my machine. I suspect it is some kind of cache problem.

The MEF loading code looks like this:

using (var catalog = new AggregateCatalog()) {

    Console.WriteLine("Loading components from {0}", folder);

    catalog.Catalogs.Add(new DirectoryCatalog(folder, "*.dll"));

    using (var container = new CompositionContainer(catalog)) {
        try {
        catch (ReflectionTypeLoadException ex) {
            foreach (var loaderException in ex.LoaderExceptions) {
               // log loading error

foreach (var assembly in _allComponents.GroupBy(x => x.GetType().Assembly)) {
    Console.WriteLine("Loaded from {0}", assembly.Key.CodeBase);

The result from the code above looks like

Loading components from C:\NewPlugins
Loaded from C:\OldPlugins
share|improve this question
Could it be that you have assemblies with the same identity in both directories? If so, make your assemblies strong named and increment the version whenever you create an update to a plugin. –  Panos Rontogiannis Mar 9 '13 at 22:26
Yes, of course they have the same identity. If that is the issue I think DirectoryCatalogis a bad name since it loads assemblies by identity and not from a directory. –  adrianm Mar 10 '13 at 12:59
add comment

1 Answer

up vote 0 down vote accepted

Since, according to your comment, you are having in both directories assemblies with the same identity, the output from your code above, is normal. This is not an issue with DirectoryCatalog. It does load try to load an assembly from the specific directory but the CLR will not load it if an assembly with the same identity is are already loaded in the current AppDomain. It doesn't matter from where the assembly was loaded, all it matters is the identity.

The solution is to make your assemblies strong named and increment the version whenever you create an update to a plugin. This way the assemblies in the NewPlugins directory will have a different identity from the ones already loaded from OldPlugins directory.

If you are interested in learning how assemblies are loaded have a look at Suzanne Cook's blog entries on assembly loading.

share|improve this answer
I know how assemblies are loaded. My interpretation was, just as you say, that CLR only considered identity on assemblies loaded in the same appdomain (so you can't load two different assemblies with the same identity). The assemblies in the OldPlugins are only loaded by a completely different application on the same machine so apparently the identity lookup is cross-appdomain. (Still think it is an issue with DirectoryCatalog which should force loading from the directory) –  adrianm Mar 11 '13 at 10:27
@adrianm You can load two assemblies with the same identity form different locations by using Assembly.LoadFile. DirectoryCatalog uses Assembly.Load(AssemblyName) though. The way the CLR loads assemblies is very complicated. Everytime I read about it, it seems that I understand something for the first time. I'm not sure what you mean about different applications. I thought you were trying to load both versions on the same AppDomain. Do you use gacutil to install these assemblies on the GAC? –  Panos Rontogiannis Mar 11 '13 at 11:00
I got one instance of the application running on the server in the OldPlugins folder. Now I put an updated version of the application and/or plugins in the NewPlugins folder on the same server (e.g. to test new functionality). When I start the updated application it still loads the assemblies from the OldPlugins folder. There is no GAC involved. I just point DirectoryCatalog to the startup folder of the application. –  adrianm Mar 11 '13 at 11:20
add comment

Your Answer


