MEF parts list sometimes empty

Question

I'm currently using MEF and a DirectoryCatalog to load some parts from some extension DLLs. It works for me, and most of the people that use the program, but some users experience the parts not being loaded at all. Collecting some debug information, it seems that MEF does load the DLLs (catalog.LoadedFiles lists them), but that no parts are listed in catalog.Parts.

One user is on XP sp3 and one is on Windows 7, so I don't think that the OS is the problem. Does anyone have some idea of why this would be happening?

The following is the code that actually creates the container, in case it would help with anything.

        private static IEnumerable<Task> CreateTypes()
    {
        CompositionContainer container = GetContainer();
        var exp = container.GetExports<Task>();
        return exp.Select(e => e.Value);
    }

    private static CompositionContainer container;
    public static CompositionContainer GetContainer()
    {
        if (container != null)
            return container;

        DirectoryCatalog catalog = new DirectoryCatalog(ExtensionDirectory, "*.dll");
        container = new CompositionContainer(catalog);
        return container;
    }

Cherey

are there no errors while creating the container? – Hesitant

No, creating the container is fine. It's just that the parts list will be empty for some people. I've updated with code, though not sure how helpful it will be. – Cherey

Could be related to ACLs. Can you verify that the user has rights to execute the files? – Gardia

I'm not sure how to do that. But, from the paths, I can see that one of them is Program Files, but the other one is in "C:\Spiele" which sounds like a user-created folder (it means "Games" in German, apparently, so I can't see that being a problem). However, I deployed both the main executable and the extension DLLs in the same folder, so it seems like they should be able to read/execute both or neither of them. – Cherey

@Cherey i know Win7 can complain when doing stuff with C:\Program Files.. maybe an issue? – Bridging

Answer 1

(Yes, I'm answering my own question...more than a year later...)

http://mikehadlow.blogspot.com/2011/07/mef-directorycatalog-fails-to-load.html

Basically, because some people downloaded the program using IE then unzipped with Windows Explorer, the DLLs were marked as being from the internet, so MEF refused to load their parts, though they still showed up inside the catalog.

The solution (for my situation at least) was simply to delete the alternate data streams that said that the DLLs were from the internet, as described in the above link.

Cherey

Answer 2

but the other one is in "C:\Spiele" which sounds like a user-created folder

Reminds me of this:

Assembly Load Issues

In .NET, there are different contexts into which an assembly can be loaded. The default load context is generally the best one to use, but it cannot load assemblies that are not in the application base directory, subdirectories of the application base which are included in the probing path, or the GAC. When using a DirectoryCatalog or passing a path to the AssemblyCatalog constructor, MEF will attempt to load assemblies in the default load context. However, if the assemblies are not in the probing path or the GAC, this will not be possible, and MEF will load them in the load-from context instead.

The load-from context can lead to type identity issues that result in an InvalidCastException, MissingMethodException, or other errors. In order to avoid these issues in a MEF application, you can put any extension directories under the application base directory, and add them to the probing private path in your application configuration file. For other options and more information about assembly loading in .NET, see the Best Practices for Assembly Loading MSDN document.

See the source "How to Debug and Diagnose MEF Failures" for more debugging information and tools.

Portentous