Best way to check if a DLL file is a CLR assembly in C#

Question

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?

Answer 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.

Answer 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

Answer 3

My current reputation is insufficient to comment directly on Jeremy's answer which works well for 32-bit DLLs. But I had to refine it for 64-bit DLLs, which appear to have more Windows-specific COFF fields.

As described by Microsoft, the COFF Magic number indicates if the format is PE32 (32-bit) or PE32+ (64-bit). If the latter, then the offset to the Data Directories is 112 bytes instead of 96.

// After the COFF header, the first COFF field is a Magic Number.
UInt16 coffMagic = reader.ReadUInt16();

// Skip remaining fields to reach data directories.  See:
// https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#optional-header-image-only
if (coffMagic == 0x010B)
{
    // It's a 32-bit DLL.  96 bytes of COFF fields.
    // Subtract 2 for the magic number we just read.
    fs.Position += (96 - 2);
}
else if (coffMagic == 0x020B)
{
    // It's a 64-bit DLL.  112 bytes of COFF fields.
    // Subtract 2 for the magic number we just read.
    fs.Position += (112 - 2);
}

Answer 4

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.

Answer 5

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.

Answer 6

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

Answer 7

Update 2020:

This should be the easiest way to detect if the dll is a .Net library:

public bool IsNetAssembly(string fileName)
{
    try
    {
        AssemblyName.GetAssemblyName(fileName);
    }
    catch (BadImageFormatException)
    {
        // not a .Net Assembly
         return false;
    }
    
    return true;
}

Answer 8

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;
        }
    }