BadImageFormatException when non-module non .NET DLL present in directory

Topics: Prism v2 - WPF 3.5
Apr 18, 2010 at 3:33 PM

Hi,

I am loading all modules from a directory into the module catalog. One of the modules has a reference to a DLL that requires another DLL to be in the same directory (Module A references B.dll that needs C.dll to be in the same directory). Only C.dll is not a .net assembly, I believe (it's third party).

When I execute 

        protected override IModuleCatalog GetModuleCatalog()        {            return new DirectoryModuleCatalog() { ModulePath = @".\" };        }

I get a BadImageFormatException,The module was expected to contain an assembly manifest. What can I do about that? I want it to skip that DLL.

Apr 19, 2010 at 6:48 PM

Hi,

A possible way to workaround your scenario would be inheriting from the DirectoryModuleCatalog and overriding the InnerLoad method to use a custom ModuleInfoLoader (the default one is private and most of its methods are internal so it cannot be extended). In the LoadAssemblies method of your custom loader you would add a catch block for this kind of exception:

public void LoadAssemblies(IEnumerable<string> assemblies)
            {
                foreach (string assemblyPath in assemblies)
                {
                    try
                    {
                        Assembly.ReflectionOnlyLoadFrom(assemblyPath);
                    }
                    catch (FileNotFoundException)
                    {
                        // Continue loading assemblies even if an assembly can not be loaded in the new AppDomain
                    }
                    catch (BadImageFormatException)
                    {
                        //Your code here
                    }
                }
            }

This approach will still provide the automatic capabilities of deploying new modules by creating the assembly and does not require any configuration.

Another possible approach if you want explicit control about the assemblies to load could be using a configuration file to populate the catalog. This is probably something that you might not be inclined to do, as you probably selected the DirectoryCatalog approach to avoid having to configure any files, but it avoids having to create the extra classes.

This issue is registered in the Issue Tracker so you might want to vote for it and the team might take the suggestion into account for a future version.

Please let me know if this helps.

Damian Schenkelman
http://blogs.southworks.net/dschenkelman

Apr 19, 2010 at 7:17 PM

Great thanks for the info! I didn't look in the issuetracker, shame on me. I voted.

Jasper