Best way to check if a DLL file is a CLR assembly

问题:

What is the best way to check if a DLL file is a Win32 DLL or if it is a CLR assembly. At the moment I use this code

    try
    {
        this.currentWorkingDirectory = Path.GetDirectoryName(assemblyPath);

        //Try to load the assembly.
        assembly = Assembly.LoadFile(assemblyPath);

        return assembly != null;
    }
    catch (FileLoadException ex)
    {
        exception = ex;
    }
    catch (BadImageFormatException ex)
    {
        exception = ex;
    }
    catch (ArgumentException ex)
    {
        exception = ex;
    }
    catch (Exception ex)
    {
        exception = ex;
    }

    if (exception is BadImageFormatException)
    {
        return false;
    }

But I like to check before loading because I do not want those exceptions (time).

Is there a better way?

回答1:

Check the PE header:

DOS header starts at 0x0, the DWORD at 0x3c contains a pointer to the PE signature (usually 0x80) which is 4 bytes, the next 20 bytes is the COFF header and then there is the PE header (at 0x9. The PE header is 224 bytes and contains the data directory (at 96 bytes into the PE header = 0xf. The 15th entry (at 0x16 is the CLR header descriptor (sometimes called the COM descriptor, but this does not have anything to do with COM). If this is empty (ie 0 in the 8 bytes from 0x168 to 0x16f) then the file is not a .NET assembly. If you want to check if it is a COM DLL then you should look to see if it exports GetClassObject.

Ref.

UPDATE: there is a more '.NET' way of accomplishing this:

Use Module.GetPEKind method and check the PortableExecutableKinds Enumeration:

NotAPortableExecutableImage The file is not in portable executable (PE) file format.

ILOnly The executable contains only Microsoft intermediate language (MSIL), and is therefore neutral with respect to 32-bit or 64-bit platforms.

Required32Bit The executable can be run on a 32-bit platform, or in the 32-bit Windows on Windows (WOW) environment on a 64-bit platform.

PE32Plus The executable requires a 64-bit platform.

Unmanaged32Bit The executable contains pure unmanaged code.

回答2:

If an assembly gets loaded eg Assembly.LoadFile(dotNetDllorExe) and doesn’t throw any exception, it’s a valid .NET assembly. If it’s not then it’ll throw a “BadImageFormatException”.

The idea of checking weather a file is assembly or not by loading it and checking if exception is thrown or not; doesn’t seem to be too clean. After all exceptions are supposed to be used exceptionally.

---

.NET assemblies are regular Win32 PE files, the operating System doesn’t differentiate between .NET assemblies and Win32 executable binaries, they are the same normal PE files. So how does the System work out if a DLL or EXE is a managed assembly in order to load the CLR?

It validates the file header to check if it’s a managed assembly or not. In the ECMA Specifications Partition II – Metadata which is shipped along with .NET SDK you see there is a separate CLI Header in the PE Format. It is the 15th data directory in the PE Optional Headers. So, in simple terms, if we have value in this data directory, then it means this is a valid .NET assembly, otherwise it's not.

internal static class PortableExecutableHelper
{
    internal static bool IsDotNetAssembly(string peFile)
    {
        uint peHeader;
        uint peHeaderSignature;
        ushort machine;
        ushort sections;
        uint timestamp;
        uint pSymbolTable;
        uint noOfSymbol;
        ushort optionalHeaderSize;
        ushort characteristics;
        ushort dataDictionaryStart;
        uint[] dataDictionaryRVA = new uint[16];
        uint[] dataDictionarySize = new uint[16];


        Stream fs = new FileStream(peFile, FileMode.Open, FileAccess.Read);
        BinaryReader reader = new BinaryReader(fs);

        //PE Header starts @ 0x3C (60). Its a 4 byte header.
        fs.Position = 0x3C;

        peHeader = reader.ReadUInt32();

        //Moving to PE Header start location...
        fs.Position = peHeader;
        peHeaderSignature = reader.ReadUInt32();

        //We can also show all these value, but we will be       
        //limiting to the CLI header test.

        machine = reader.ReadUInt16();
        sections = reader.ReadUInt16();
        timestamp = reader.ReadUInt32();
        pSymbolTable = reader.ReadUInt32();
        noOfSymbol = reader.ReadUInt32();
        optionalHeaderSize = reader.ReadUInt16();
        characteristics = reader.ReadUInt16();

        /*
            Now we are at the end of the PE Header and from here, the
                        PE Optional Headers starts...
                To go directly to the datadictionary, we'll increase the      
                stream’s current position to with 96 (0x60). 96 because,
                        28 for Standard fields
                        68 for NT-specific fields
            From here DataDictionary starts...and its of total 128 bytes. DataDictionay has 16 directories in total,
            doing simple maths 128/16 = 8.
            So each directory is of 8 bytes.
                        In this 8 bytes, 4 bytes is of RVA and 4 bytes of Size.

            btw, the 15th directory consist of CLR header! if its 0, its not a CLR file :)
     */
        dataDictionaryStart = Convert.ToUInt16(Convert.ToUInt16(fs.Position) + 0x60);
        fs.Position = dataDictionaryStart;
        for (int i = 0; i < 15; i++)
        {
            dataDictionaryRVA[i] = reader.ReadUInt32();
            dataDictionarySize[i] = reader.ReadUInt32();
        }
        if (dataDictionaryRVA[14] == 0)
        {
            Console.WriteLine("This is NOT a valid CLR File!!");
            return false;
        }
        else
        {
            Console.WriteLine("This is a valid CLR File..");
            return true;
        }
        fs.Close();
    }
}

ECMA Ref, Blog Ref

回答3:

Faced with the same problem in the past, I resorted to using your reflection approach because the alternative is to manually read the PE header like this. Just seemed like overkill for my scenario, but it may be useful to you.

回答4:

You didn't specify whether you have to do this in code, or if you just personally need to know if a file you're looking at on your system is a .NET assembly (which maybe you think requires you writing your own code to do so). If the latter, you can use Dependency Walker to see if it has a dependency on MSCOREE.dll, which is the .Net runtime engine.

回答5:

You could use something like:

        AssemblyName assemblyName = null;

        try
        {
            assemblyName = AssemblyName.GetAssemblyName(filename);
        }
        catch (System.IO.FileNotFoundException ex)
        {
            throw new Exception("File not found!", ex);
        }
        catch (System.BadImageFormatException ex)
        {
            throw new Exception("File is not an .Net Assembly.", ex);
        }

Please also check out: https://msdn.microsoft.com/en-us/library/ms173100.aspx

回答6:

You can read the first two bytes from the file, if the bytes are "MZ" then try to read the assembly name to determine (microsoft slow way) the validity of the assembly.

    public static bool isValidAssembly (string sFileName)
    {
        try
        {
            using (FileStream fs = File.OpenRead(sFileName))
            {
                if ((fs.ReadByte() != 'M') || (fs.ReadByte() != 'Z'))
                {
                    fs.Close();
                    return false;
                }
                fs.Close();
            }

            // http://msdn.microsoft.com/en-us/library/ms173100.aspx
            object foo = SR.AssemblyName.GetAssemblyName(sFileName);
            return true;
        }
        catch 
        {
            return false;
        }
    }