3

Possible Duplicate:
How to determine whether a DLL is a managed assembly or native (prevent loading a native dll)?
Is this DLL managed or unmanaged?

My scenario: I am beginning the process of moving a large number of DLL resources from C++ to C# managed code. These DLLs will have to exist in a common directory, and they are not statically linked (referenced). Instead, they are loaded using Assembly.LoadFile() as needed.

In order to determine which are new (managed) DLLs, I am attempting to loop through the files in the directory using an array of FileInfo objects, and for each, loading the assembly.

The attempt to load the assembly fails, of course, when the DLL is one of the unmanaged C++ DLLs.

My question, then, is whether or not it's possible to inspect the DLL file, using Reflection or otherwise, and determine its managed/unmanaged nature.

Community
  • 1
  • 1
DonBoitnott
  • 10,787
  • 6
  • 49
  • 68

2 Answers2

1

The attempt to load the assembly fails, of course, when the DLL is one of the unmanaged C++ DLLs.

Just have a function that uses a try/catch block to attempt to load the assembly, returns true if the assmebly could be loaded or false if the appropriate type of exception is thrown.

PhonicUK
  • 13,486
  • 4
  • 43
  • 62
  • I thought along the same lines, however it's also quite possible a managed assembly could fail to load. – Lloyd Aug 29 '12 at 13:35
  • That's why you have to check what type of exception it is. A load failure because the file doesn't exist will give a different exception than if it exists but it's not a managed library. – PhonicUK Aug 29 '12 at 13:36
  • Here's something I've just found - http://msdn.microsoft.com/en-us/library/ms173100.aspx – Lloyd Aug 29 '12 at 13:37
  • Pretty much exactly what I said. "If a BadImageFormatException exception is thrown, the file is not an assembly." – PhonicUK Aug 29 '12 at 13:38
  • Yeh. Shame there's not a file version info marker for it much like there was for COM. – Lloyd Aug 29 '12 at 13:41
  • 2
    *If a BadImageFormatException exception is thrown, the file is not an assembly.*: this is wrong. If you try to load a 32bit assembly into a 64bit process, you also get a BadImageFormatException, even if the file is a .net assembly. – sloth Aug 29 '12 at 13:41
  • @BigYellowCactus also true - It looks like MS don't account for this happening. Perhaps you'd actually need 32 and 64 bit versions of your code to both check and examine both results separately. – PhonicUK Aug 29 '12 at 13:43
0

It appears you can use GetAssemblyName() to attempt to query the assembly meta data. If the call fails a BadImageException will be thrown.

class TestAssembly
{
    static void Main()
    {

        try
        {
            System.Reflection.AssemblyName testAssembly =
                System.Reflection.AssemblyName.GetAssemblyName(@"C:\Windows\Microsoft.NET\Framework\v3.5\System.Net.dll");

            System.Console.WriteLine("Yes, the file is an assembly.");
        }

        catch (System.IO.FileNotFoundException)
        {
            System.Console.WriteLine("The file cannot be found.");
        }

        catch (System.BadImageFormatException)
        {
            System.Console.WriteLine("The file is not an assembly.");
        }

        catch (System.IO.FileLoadException)
        {
            System.Console.WriteLine("The assembly has already been loaded.");
        }
    }
}
/* Output (with .NET Framework 3.5 installed):
    Yes, the file is an assembly.
*/

I shamelessly copied this from http://msdn.microsoft.com/en-us/library/ms173100.aspx if you care to read more.

Lloyd
  • 29,197
  • 4
  • 84
  • 98
  • this is wrong. If you try to load a 32bit assembly into a 64bit process, you also get a BadImageFormatException, even if the file is a .net assembly. – sloth Aug 29 '12 at 13:42
  • Hey, blame MS not me ;) You are right of course, which is why I said in a previous comment that there are other circumstances this will fail. I'll vote to close with the previous question you specified. – Lloyd Aug 29 '12 at 13:44